| From: | David Fetter <david(at)fetter(dot)org> |
|---|---|
| To: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Top-k optimizations? |
| Date: | 2005-01-14 01:43:31 |
| Message-ID: | 20050114014331.GB11163@fetter.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Folks,
As this came up in a work situation, I was wondering a little bit
about the top-k issue. Right now, top-k is implemented (most easily,
I think) via a SELECT with a LIMIT and no OFFSET. 3 questions arise
from this.
1. Are there currently any optimizations specific to top-k in
PostgreSQL? If so, what are they?
2. What kinds of top-k optimizations *can't* be part of PostgreSQL
(things that would break MVCC, e.g.)?
3. What kinds of top-k optimizations might (eventually) be included
in PostgreSQL?
Hoping this stimulates some friendly & informative discussion... :)
Cheers,
D
--
David Fetter david(at)fetter(dot)org http://fetter.org/
phone: +1 510 893 6100 mobile: +1 415 235 3778
Remember to vote!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc G. Fournier | 2005-01-14 02:12:27 | FATAL: catalog is missing 1 attribute(s) for relid 16396 |
| Previous Message | Tom Lane | 2005-01-14 01:27:21 | Re: Bug? 8.0 does not use partial index |