| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: some aspects of our qsort might not be ideal |
| Date: | 2022-06-23 15:04:17 |
| Message-ID: | CAH2-Wz==W5vvXkUcRsM7Uo3tGOTBN_wqd1wbx3ivskUsVZJ2HQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 23, 2022 at 7:51 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> I think that mostly has to do with reliability / stability of ORDER BY
> in combination with LIMIT and OFFSET, even though right now we cannot
> fully guarantee such stability due to unstable results from underlying
> plan nodes.
The current qsort isn't stable. While quicksort is never stable, our
particular implementation has fairly significant optimizations that
strongly rely on not using a stable sort. In particular, the B&M
optimizations for duplicate elements.
These optimizations make things like datum tuplesorts for
'SELECT(DISTINCT mycol) ...' style queries on low cardinality columns
extremely fast. We're not really sorting so much as bucketing. This is
based on Dijkstra's Dutch national flag problem.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2022-06-23 15:08:07 | Re: some aspects of our qsort might not be ideal |
| Previous Message | Matthias van de Meent | 2022-06-23 14:51:24 | Re: some aspects of our qsort might not be ideal |