Skip site navigation (1) Skip section navigation (2)

Better implementation of CREATE TABLE AS ... WITH NO DATA

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Better implementation of CREATE TABLE AS ... WITH NO DATA
Date: 2011-11-24 19:22:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
it's pointed out that our documentation claims the WITH [NO] DATA option
works for all variants of CREATE TABLE AS.  But in fact it's only
implemented for the SelectStmt variant, not for the ExecuteStmt variant,
and the ugly kluge used for SelectStmt (paste on a LIMIT 0 at parse
time) isn't going to work for the ExecuteStmt case.

What I'm considering doing to improve this is to add a bool field
"skipData" or some such to IntoClause.  By default that would be false,
but the CREATE TABLE AS productions could set it true when they have
WITH NO DATA.  Then we'd need to add an execution-time test; the most
expedient way seems to be to add something like this to ExecutorRun:

	if (estate->es_select_into &&
	    direction = NoMovementScanDirection;

which will cause it to skip the ExecutePlan call.  In the normal case
this adds just one boolean test to ExecutorRun, so I don't think it
represents a measurable slowdown.  The EXECUTE code path needs no
changes since it's just passing the IntoClause through to the executor.

While at it, it occurs to me that we could handle the
IntoClause.colNames option for the ExecuteStmt case if we were to move
the responsibility for plastering on the substitute column names into
the executor's OpenIntoRel, instead of making parse analysis do this
(which is also pretty klugy, see applyColumnNames callers).

Any objections or better ideas?

			regards, tom lane

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-11-24 20:01:20
Subject: Re: Notes on implementing URI syntax for libpq
Previous:From: Jeff DavisDate: 2011-11-24 19:01:52
Subject: Re: Obstacles to user-defined range canonicalization functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group