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

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
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-13 16:43:42
Message-ID: Pine.BSF.4.10.10010130940160.51468-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


With how we do things right now, does it actually gain us anything
to have a presorted table? Do we know not to do a seek on an index scan
if we're already at the right location in the heap file? We can't assume
the table is sorted (unless it hasn't been modified), so it's not like we
can sequence scan and stop when the bounds are met. If we don't do the
seek though, this could definately be good for mostly static data since
that might allow us to mostly not do seeks on normal conditions.

On Fri, 13 Oct 2000, Zeugswetter Andreas SB wrote:

>
> > > > He does ask a legitimate question though. If you are
> > going to have a
> > > > LIMIT feature (which of course is not pure SQL), there
> > seems no reason
> > > > you shouldn't be able to insert the result into a table.
> > >
> > >
> >
> > 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.
>
> Andreas
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ross J. Reedstrom 2000-10-13 17:00:28 Re: [HACKERS] My new job
Previous Message Dan Moschuk 2000-10-13 15:05:02 -d 2 frustration