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 по дате отправления: