| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(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>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: record identical operator |
| Date: | 2013-09-20 15:05:06 |
| Message-ID: | 20130920150506.GC2706@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
> > I'm trying to figure out why that's a perfectly acceptable solution for
> > users running views with GROUP BYs, but apparently it isn't sufficient
> > for mat views?
>
> Err, because users wrote a GROUP BY? They haven't (neccessarily) in the
> cases of the matviews we're talking about?
Sure; my thinking was going back to what Hannu had suggested where we
have a mechanism to see if the value was updated (using xmin or similar)
and then update it in the mat view in that case, without actually doing
a comparison at all.
That wouldn't necessairly work for the GROUP BY case, but that situation
doesn't work reliably today anyway. If we solve the GROUP BY case in
SQL for these types then we could use the same for mat views, but we've
been happy enough to ignore the issue thus far.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2013-09-20 15:05:22 | Re: Freezing without write I/O |
| Previous Message | Kevin Grittner | 2013-09-20 15:01:20 | Re: record identical operator |