Re: MV patch broke users of ExplainOneQuery_hook

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MV patch broke users of ExplainOneQuery_hook
Date: 2013-04-09 18:17:21
Message-ID: 1365531441.45717.YahooMailNeo@web162905.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
>>> Any objections to my pushing the patch I posted Friday to draw a
>>> distinction between populated and scannable, which also attempted
>>> to address a couple points raised by you, or would you rather the
>>> code didn't change at the moment?
>
>> I didn't look at it yet

> [ looks... ]  TBH, most of that code is code that I'd like to see
> removed, not just renamed; I do not think its problems are primarily
> cosmetic.  However I have no objection to pushing what you have for
> the moment.  Perhaps clarifying the intent will help us think about
> where to go from here.

My hope is that it will do that at a minimum.  Thanks for looking
at this, BTW.

> One point that does come to mind, though, as long as you're trying
> to draw a distinction between "populated" and "scannable", is why
> pg_dump should be paying attention to one or the other; or indeed
> why it should care about the matviews' current contents at all.
> It seems to me that it would be more useful to not pay any attention
> to that, but instead have a command-line switch to control whether
> the dump includes commands to repopulate matviews or not.  Driving
> this off the current state seems rather akin to expecting pg_dump
> to reproduce the contents of indexes exactly, rather than build
> them from scratch.

I guess my thinking was that without that you might dump and
restore and have a database which is not usable without further
work (if the matview data is needed for correct operation) or you
might populate a matview which was not yet intended to *be*
populated.  I'm not tied to that, but it seemed reasonable and
likely to be useful.  It's going to be hard to sell me that by
default a materialized view which has not been populated should
quietly behaves as though empty or should execute the underlying
query as though it were a "normal" view -- those seem like
correctness issues to me; but behavior for pg_dump seems less
definite.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen R. van den Berg 2013-04-09 19:34:32 Re: Success (Re: page 1 of relation global/11787 was uninitialized)
Previous Message Florian Pflug 2013-04-09 18:04:52 Re: Success (Re: page 1 of relation global/11787 was uninitialized)