Re: PoC: Partial sort - Mailing list pgsql-hackers

From Robert Haas
Subject Re: PoC: Partial sort
Date
Msg-id CA+TgmoZ3yMwtQ35cHO0p7H6jBkVmACY3cpPAZK6GC7yE0-R7JQ@mail.gmail.com
Whole thread Raw
In response to Re: PoC: Partial sort  (Marti Raudsepp <marti@juffo.org>)
List pgsql-hackers
On Wed, Feb 19, 2014 at 1:39 PM, Marti Raudsepp <marti@juffo.org> wrote:
> On Wed, Feb 12, 2014 at 11:54 PM, Marti Raudsepp <marti@juffo.org> wrote:
>> With partial-sort-basic-1 and this fix on the same test suite, the
>> planner overhead is now a more manageable 0.5% to 1.3%; one test is
>> faster by 0.5%.
>
> Ping, Robert or anyone, does this overhead seem bearable or is that
> still too much?
>
> Do these numbers look conclusive enough or should I run more tests?

Tom should really be the one to comment on this, I think.  I read
through the patch quickly and it looks much less scary than the early
versions, but it's not obvious to me whether the remaining overhead is
enough to worry about.  I'd need to spend more time studying it to
form a really sound opinion on that topic, and unfortunately I don't
have that time right now.

I think it'd be interesting to try to determine specifically where
that overhead is coming from.  Pick the test case where it's the worst
(1.3%) and do a "perf" with and without the patch and look at the
difference in the call graph.  It's possible we could have changes on
that order of magnitude just from more or less fortuitous code layout
decisions as code shifts around, but it's also possible that there's a
real effect there we should think harder about.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: should we add a XLogRecPtr/LSN SQL type?
Next
From: Shigeru Hanada
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)