Re: Last Commitfest patches waiting review - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Last Commitfest patches waiting review
Date
Msg-id CAM3SWZQhTk5OKWRu5-e=zPkWtpBVMF1Xp6M824+RY+s3Xa+5Gw@mail.gmail.com
Whole thread Raw
In response to Re: Last Commitfest patches waiting review  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Last Commitfest patches waiting review
List pgsql-hackers
On Mon, Oct 6, 2014 at 11:27 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Well, really, I was just suggesting that I can spend more time on the
> patch, but not immediately.

We haven't really talked about the idea of the HyperLogLog-based abort
mechanism - the actual cost model - even though I thought we'd have
discussed that extensively by now. Maybe I'm reading too much into
that, but my guess is that that's because it's a particularly hard
thing to have an opinion on. I think that It might not be a bad idea
to have another opinion on that in particular.

We've historically resisted this kind of special case optimization,
and yet the optimization is likely to be very effective in many
representative cases. Plus, some aspects of the cost model are a bit
fuzzy, in a way that things in the executor ordinarily are not, and so
I can understand how this would present any reviewer with difficulty.

By the way, the original description of this approach to accelerating
sorts I saw was here, in this 2001 paper:


http://lgis.informatik.uni-kl.de/archiv/wwwdvs.informatik.uni-kl.de/courses/DBSREAL/SS2001/Vorlesungsunterlagen/Implementing_Sorting.pdf

(Under "2.4 Cache-optimized techniques")
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: copy.c handling for RLS is insecure
Next
From: Tom Lane
Date:
Subject: Re: copy.c handling for RLS is insecure