From: | Jeremy Harris <jgh(at)wizmail(dot)org> |
---|---|
To: | Arthur Silva <arthurprs(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Abbreviated keys for text cost model fix |
Date: | 2015-03-03 10:00:37 |
Message-ID: | 54F58645.1060101@wizmail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03/03/15 03:08, Arthur Silva wrote:
> Does it always perform mergesort instead of quicksort when enabled?
Yes; there seemed no advantage to any additional complexity.
The merge consistently performs fewer comparisons than the
quicksort, on random input - and many fewer if there are
any sorted (or reverse-sorted) sections. However, it also
consistently takes slightly longer (a few percent). I was
unable to chase this down but assume it to be a cacheing
effect. So I don't currently think it should replace the
current sort for all use.
If the planner can identify cases where there is some pre-sort
in the input (CLUSTER was mentioned?), or maybe a correlated
index, it could be worthwhile.
Also useful might be very-expensive comparison cases,
and distinct-output cases (uniqification is supported at
each submerge stage, so data disappears early).
There's potential for running submerges in parallel
using multiple cores, but I've not worked on that.
--
Cheers,
Jeremy
From | Date | Subject | |
---|---|---|---|
Next Message | Kouhei Kaigai | 2015-03-03 10:01:03 | Re: One question about security label command |
Previous Message | 张元超 | 2015-03-03 09:32:35 | One question about security label command |