On 09/19/2013 10:54 AM, Dimitri Fontaine wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> There are examples in the patch and this thread, but rather than
>> reference back to those I'll add a new one. Without the patch:
> Thanks much for doing that.
>
>> The problem, as I see it, is that the view and the concurrently
>> refreshed materialized view don't yield the same results for the
>> same query. The rows are equal, but they are not the same. With
>> the patch the matview, after RMVC, looks just the same as the view.
> My understanding is that if you choose citext then you don't care at all
> about the case, so that the two relations actually yield the same
> results for the right definition of "same" here: the citext one.
>
> In other words, the results only look different in ways that don't
> matter for the datatype involved, and I think that if it matters to the
> user then he needs to review is datatype choices or view definition.
>
> So my position on that is that your patch is only adding confusion for
> no benefits that I'm able to understand.
The aim is to have a view and materialized view return the same results.
If they do not, the user is guaranteed to be confused and to consider
the matview implementation broken
the patch solves the general problem of "when the table changes, refresh"
After saying it like this, the problem could also be solved by including
xmin(s) for rows from underlying table(s)in the matview.
Would this be a better approach ?
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
