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
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 |