Re: record identical operator

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Steve Singer <steve(at)ssinger(dot)info>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: record identical operator
Date: 2013-09-23 21:36:26
Message-ID: 20130923213626.GM2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> In this case even something
> like AVG() could produce the same result as it did before the update.
> And you'd surely want to avoid updating the matview if the new value
> was the same as what was already stored in the matview (but not if it
> was equal but not the same).

BTW, I'm wondering how you're going to explain that, with an
optimization of MAX() for matviews that only looks at the records which
were updated, that we decided to change 'A' to 'a' on a citext column
because they were binary different, yet if you considered all of the
rows under the MAX(), 'A' would have nearly always come first and
therefore would have been the more likely candidate (and what the user
probably would have gotten running the query themselves).

Also, as asked, I'll work up an example of how the matview can produce
a different result from the regular view in some cases, even with the
binary equality stuff.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2013-09-23 21:36:56 Re: GIN improvements part 1: additional information
Previous Message Peter Eisentraut 2013-09-23 21:26:42 Re: UTF8 national character data type support WIP patch and list of open issues.