On 30/03/17 16:04, Pavan Deolasee wrote:
>
>
> On Thu, Mar 30, 2017 at 7:27 PM, Robert Haas <robertmhaas@gmail.com
> <mailto:robertmhaas@gmail.com>> wrote:
>
> On Thu, Mar 30, 2017 at 6:37 AM, Pavan Deolasee
> <pavan.deolasee@gmail.com <mailto:pavan.deolasee@gmail.com>> wrote:
> > I think we can fix that by comparing compressed values. I know you had
> > raised concerns, but Robert confirmed that (IIUC) it's not a problem today.
>
> I'm not sure that's an entirely fair interpretation of what I said.
> My point was that, while it may not be broken today, it might not be a
> good idea to rely for correctness on it always being true.
>
>
> I take that point. We have a choice of fixing it today or whenever to
> support multiple compression techniques. We don't even know how that
> will look like and whether we will be able to look at compressed data
> and tell whether two values are compressed by exact same way.
>
While reading this thread I am thinking if we could just not do WARM on
TOAST and compressed values if we know there might be regressions there.
I mean I've seen the problem WARM tries to solve mostly on timestamp or
boolean values and sometimes counters so it would still be helpful to
quite a lot of people even if we didn't do TOAST and compressed values
in v1. It's not like not doing WARM sometimes is somehow terrible, we'll
just fall back to current behavior.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services
