Re: code question: storing INTO relation

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

In response to

Responses

Browse pgsql-hackers by date

  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