| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Hannu Krosing <hannu(at)skype(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, John Hansen <john(at)geeknet(dot)com(dot)au>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Does anybody use ORDER BY x USING y? |
| Date: | 2005-09-19 03:34:28 |
| Message-ID: | 18053.1127100868@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> That would be an extremely bad idea, because it would immediately remove
>> index scans as one way to meet an ORDER BY.
> Well couldn't the index scan be taught to go fetch the NULLs in a separate
> traversal?
(1) IS NULL is not an indexable operation, so no, not without
significant overhaul of the index AM API.
(2) This propagates a problem that is specific to orderable indexes (ie
btree) into code that is generic to all indexes, and thus creates the
problem of how do you deal with specifying NULL ordering without any
definition of ordering for non-NULLs.
(3) You still have to invent a mechanism to define whether you want
nulls first or last ... and make sure that that mechanism works for
plans that use explicit SORT steps as well as those that use index
scans.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc G. Fournier | 2005-09-19 03:47:21 | Re: Beta2 Wrap Up ... |
| Previous Message | Tom Lane | 2005-09-19 03:23:01 | Re: Does anybody use ORDER BY x USING y? |