Re: Materialized views WIP patch - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Materialized views WIP patch
Date
Msg-id 51341D37.5020506@2ndquadrant.com
Whole thread Raw
In response to Re: Materialized views WIP patch  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 03/04/2013 08:27 AM, Josh Berkus wrote:
>> There's a much more fundamental reason why this will never happen, which
>> is that the query planner is not licensed to decide that you only want
>> an approximate and not an exact answer to your query.
> I think it would be worth talking about when someone wants to implement
> it.  I'd imagine it would require setting a GUC, though, which would be
> off by default for obvious reasosn.
I'm not a fan of this, even with a GUC. Imagine doing remote debugging
by email/phone. There are enough things to check already ("does your
application REALLY commit that transaction?") without also having to
deal with settings that can cause a potentially out of date view of the
data to be used without it being visible in the query its self.

I hate to even say it, but this is where a per-query [redacted] would be
good, so we could say in the query text that this query may use matviews
that are not perfectly up to date.

At this point it's all hand-waving anyway, since no feature to allow the
planner to automatically rewrite a subtree of a query to use a matview
instead exists.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services




pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Partial patch status update, 3/3/13
Next
From: Craig Ringer
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]