| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Incremental sort |
| Date: | 2017-04-26 16:56:30 |
| Message-ID: | CAH2-Wzk66aLr78F1WoDF2EdJO2g3HrgKHjoYt0F2j-+vSDCXjg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 26, 2017 at 8:39 AM, Alexander Korotkov
<a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> That appears to be wrong. I intended to make cost_sort prefer plain sort
> over incremental sort for this dataset size. But, that appears to be not
> always right solution. Quick sort is so fast only on presorted data.
As you may know, I've often said that the precheck for sorted input
added to our quicksort implementation by a3f0b3d is misguided. It
sometimes throws away a ton of work if the presorted input isn't
*perfectly* presorted. This happens when the first out of order tuple
is towards the end of the presorted input.
I think that it isn't fair to credit our qsort with doing so well on a
100% presorted case, because it doesn't do the necessary bookkeeping
to not throw that work away completely in certain important cases.
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-04-26 16:57:00 | Re: Partition-wise aggregation/grouping |
| Previous Message | Robert Haas | 2017-04-26 16:52:23 | Re: Declarative partitioning - another take |