"Craig A. James" <[EMAIL PROTECTED]> writes:
> You can also use this trick when the optimizer is asked for "fastest first
> result." Say you have a cursor on a column of numbers with good
> distribution. If you do a bucket sort on the first two or three digits only,
> you know the first "page" of results will be in the first bucket. So you
> only need to apply qsort to that first bucket (which is very fast, since it's
> small), and you can deliver the first page of data to the application. This
> can be particularly effective in interactive situations, where the user
> typically looks at a few pages of data and then abandons the search.
> I doubt this is very relevant to Postgres. A relational database has to be
> general purpose, and it's hard to give it "hints" that would tell it when to
> use this particular optimization.
Actually, LIMIT does nicely for that hint; the PG planner has definitely
got a concept of preferring fast-start plans for limited queries. The
real problem in applying bucket-sort ideas is the lack of any
datatype-independent way of setting up the buckets.
Once or twice we've kicked around the idea of having some
datatype-specific sorting code paths alongside the general-purpose one,
but I can't honestly see this as being workable from a code maintenance
standpoint.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
