Re: kqueue - Mailing list pgsql-hackers

From Tom Lane
Subject Re: kqueue
Date
Msg-id 23339.1473792428@sss.pgh.pa.us
Whole thread Raw
In response to Re: kqueue  (Andres Freund <andres@anarazel.de>)
Responses Re: kqueue  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2016-09-13 12:43:36 -0400, Tom Lane wrote:
>> Also, if it's only a win on machines with dozens of CPUs, how many
>> people are running *BSD on that kind of iron?  I think Linux is by
>> far the dominant kernel for such hardware.  For sure Apple isn't
>> selling any machines like that.

> I'm not sure you need quite that big a machine, if you test a workload
> that currently reaches the poll().

Well, Thomas stated in
https://www.postgresql.org/message-id/CAEepm%3D1CwuAq35FtVBTZO-mnGFH1xEFtDpKQOf_b6WoEmdZZHA%40mail.gmail.com
that he hadn't been able to measure any performance difference, and
I assume he was trying test cases from the WaitEventSet thread.

Also I notice that the WaitEventSet thread started with a simple
pgbench test, so I don't really buy the claim that that's not a
way that will reach the problem.

I'd be happy to see this go in if it can be shown to provide a measurable
performance improvement, but so far we have only guesses that someday
it *might* make a difference.  That's not good enough to add to our
maintenance burden IMO.

Anyway, the patch is in the archives now, so it won't be hard to resurrect
if the situation changes.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: Write Ahead Logging for Hash Indexes
Next
From: Robert Haas
Date:
Subject: Re: Vacuum: allow usage of more than 1GB of work mem