From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MVCC catalog access |
Date: | 2013-06-20 14:58:59 |
Message-ID: | CA+TgmoaUJY7LoRdBzFSK_1HUrSx-TAS9qB12vbRq3D0-CtcuNw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jun 20, 2013 at 10:35 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> But I'm still on the fence about whether this is really a valid test.
>
> I think it shows that we need to be careful and do further performance
> evaluations and/or alleviate the pain by making things cheaper (say, a
> "ddl counter" in shared mem, allowing to cache snapshots for the
> syscache). If that artificial test hadn't shown problems I'd have voted
> for just going ahead and not worry further.
I tried a general snapshot counter that rolls over every time any
transaction commits, but that doesn't help much. It's a small
improvement on general workloads, but it's not effective against this
kind of hammering. A DDL counter would be a bit more expensive
because we'd have to insert an additional branch into
GetSnapshotData() while ProcArrayLock is held, but it might be
tolerable. Do you have code for this (or some portion of it) already?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2013-06-20 14:59:33 | Re: dynamic background workers |
Previous Message | Robert Haas | 2013-06-20 14:43:05 | Re: dump difference between 9.3 and master after upgrade |