Re: Postgres with pthread

From: Adam Brusselback <adambrusselback(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres with pthread
Date: 2017-12-06 17:02:41
Message-ID: CAMjNa7cHrtXRxJM50KnRBrOUhp8JO8PfYF-1b3Qpi0HQmJv_mw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Here it is formatted a little better.


So a little over 50% performance improvement for a couple of the test cases.

On Wed, Dec 6, 2017 at 11:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> writes:
> > Below are some results (1000xTPS) of select-only (-S) pgbench with scale
> > 100 at my desktop with quad-core i7-4770 3.40GHz and 16Gb of RAM:
>
> > Connections Vanilla/default Vanilla/prepared
> > pthreads/defaultpthreads/prepared
> > 10 100 191
> > 106 207
> > 100 67 131
> > 105 168
> > 1000 41 65
> > 55 102
>
> This table is so mangled that I'm not very sure what it's saying.
> Maybe you should have made it an attachment?
>
> However, if I guess at which numbers are supposed to be what,
> it looks like even the best case is barely a 50% speedup.
> That would be worth pursuing if it were reasonably low-hanging
> fruit, but converting PG to threads seems very far from being that.
>
> I think you've done us a very substantial service by pursuing
> this far enough to get some quantifiable performance results.
> But now that we have some results in hand, I think we're best
> off sticking with the architecture we've got.
>
> regards, tom lane
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-12-06 17:04:12 Re: views
Previous Message Andrzej Barszcz 2017-12-06 16:53:44 views