Re: AW: Inserting a select statement result into another ta ble

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Inserting a select statement result into another ta ble
Date: 2000-10-14 04:22:10
Message-ID: 1633.971497330@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
>> This is an interesting idea. We don't allow ORDER BY in
>> INSERT INTO ...
>> SELECT because it doesn't make any sense, but it does make sense if
>> LIMIT is used:

> An "order by" also makes sense if you want to create a presorted table
> for faster access. I don't see why we should disallow it.

In current sources:

regression=# insert into int4_tbl select * from int4_tbl order by f1;
INSERT 0 5
regression=# select * from int4_tbl;
f1
-------------
0
123456
-123456
2147483647
-2147483647
-2147483647 <<= insertion starts here
-123456
0
123456
2147483647
(10 rows)

LIMIT won't work without some further code-rejiggering, but I think
it should be made to work eventually.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-10-14 04:25:17 Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Previous Message Bruce Momjian 2000-10-14 04:20:48 Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan