From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why do we still perform a check for pre-sorted input within qsort variants? |
Date: | 2013-02-25 11:44:14 |
Message-ID: | 21372.1361792654@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> FWIW, I've been suspicious of that pre-sorted check since the day it
> went in. Bentley was my faculty adviser for awhile in grad school,
> and I know him to be *way* too smart to have missed anything as simple
> as that. But I didn't have hard evidence on which to object to it
> at the time, and indeed testing seemed to say it was a good idea:
> http://www.postgresql.org/message-id/18732.1142967137@sss.pgh.pa.us
BTW, after further review --- one thing that seems a little fishy is
that that test scaffolding made glibc's qsort look pretty good; which
was at variance with our previous experience, in which our version of
qsort seemed to dominate glibc's even before we took out the dubious
"swap_cnt" code, cf thread at
http://www.postgresql.org/message-id/Pine.LNX.4.58.0512121138080.18520@eon.cs
So there is definitely some room to argue that B&M's test scaffolding
doesn't match up with our real-world workloads. But before tinkering
too much with that code, it'd be good to understand why not, and to
have a test case we trust more.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-02-25 11:44:16 | Re: Why do we still perform a check for pre-sorted input within qsort variants? |
Previous Message | Stefan Andreatta | 2013-02-25 11:07:19 | Re: autoanalyze criteria |