From: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: code question: storing INTO relation |
Date: | 2004-10-19 00:08:58 |
Message-ID: | Pine.LNX.4.58.0410191006010.31587@linuxworld.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 18 Oct 2004, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > I've got the CREATE TABLE AS restructuring almost finished, but came
> > across something that I could use some advice on. The current code
> > stores the "into" relation (and whether or not that relation has OIDs)
> > in the Query struct. This is ugly[1], but I'm not sure how to fix it.
>
> It strikes me that as far as the executor is concerned, CREATE TABLE AS
> would be better treated as an INSERT (ie, pretend it was CREATE TABLE
> followed by INSERT/SELECT). If you did that then the idea would be to
> create the new table and add it to the query range table. Then you need
> neither any special-case code in execMain, nor a new DestReceiver.
>
> You'd still want to copy/modify the Query, but to convert it from a
> SELECT into an INSERT, which is a pretty clean transformation I think.
Just thinking of optimisations, I wonder if it would be possible to bypass
WAL (like we do for ALTER TABLE ... SET TABLESPACE) if archiving is
disabled, and fsync the newly created relfilenode after the data is inserted.
Gavin
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2004-10-19 00:51:33 | Re: Using ALTER TABLESPACE in pg_dump |
Previous Message | Tom Lane | 2004-10-18 23:37:05 | Re: code question: storing INTO relation |