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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #8606: Materialized View WITH NO DATA bug
Дата
Msg-id 21660.1385241351@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #8606: Materialized View WITH NO DATA bug  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-bugs
Kevin Grittner <kgrittn@ymail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.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

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Server may segfault when using slices on int2vector
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: BUG #8611: ECPG: unclosed comment "/*"