Re: BUG #8606: Materialized View WITH NO DATA bug

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: "j(dot)rejda(at)konektel(dot)cz" <j(dot)rejda(at)konektel(dot)cz>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #8606: Materialized View WITH NO DATA bug
Date: 2013-11-23 21:15:51
Message-ID: 21660.1385241351@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But having said that, it seems that this complaint implies that
>> CREATE MATERIALIZED VIEW ... WITH NO DATA still runs the query
>> through a planning cycle. Why is that? I can't immediately see
>> any benefit to doing so.

> Well, to be honest, it's because CREATE TABLE AS ... WITH NO DATA
> does so, and I figured that if it was needed there I didn't see why
> CREATE MATERIALIZED VIEW AS ... WITH NO DATA would be any
> different. I'm shameless in copying what seems to be working.

I looked at that a bit. The reason we have to plan, in the current code,
is that we create the target table using column type info from the output
tupdesc supplied by the executor; so we have to have a plan to fire up the
executor on, even if we aren't going to fetch any data from the plan.

It's conceivable that we could extract result type info directly from
the original query (a la DefineVirtualRelation), but it'd be a significant
amount of work and it would mean that the WITH DATA and WITH NO DATA code
paths would be almost completely disjoint. Worse, we'd still need
something pretty close to what we've got now to handle the CREATE TABLE
AS ... EXECUTE case, making that probably a third totally separate path.

So I'm thinking it's not worth the trouble to avoid a planning cycle
here.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alexei Savchik 2013-11-24 06:29:01 Fwd: BUG #8611: ECPG: unclosed comment "/*"
Previous Message Tom Lane 2013-11-23 20:39:39 Re: Server may segfault when using slices on int2vector