Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <
От | Kevin Grittner |
---|---|
Тема | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Дата | |
Msg-id | CACjxUsOwwoCsyrspbCviuYCW7zvBviHpTMLXTHY5zzD-F=CHMQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Re: pgsql: Avoid extra locks in
GetSnapshotData if old_snapshot_threshold <
Re: [HACKERS] Re: pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold < |
Список | pgsql-committers |
On Fri, May 6, 2016 at 7:48 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-05-06 19:43:24 -0500, Kevin Grittner wrote:
>> It's disappointing that I am not getting more consistent numbers,
>> but NUMA can be hard to manage that way.
>
> FWIW, in my experience, unless you disable autovacuum (or rather
> auto-analyze), the effects from non-predicable analyze runs with
> long-running snapshots are worse. I mean the numa effects suck, but in
> r/w workload effects of analyze are often much worse.
Hm. But the benefits of the patch are not there if autovacuum is
off. I'm gonna need to ponder the best way to test given all that.
> That comment reminds me of a question I had: Did you consider the effect
> of this patch on analyze? It uses a snapshot, and by memory you've not
> built in a defense against analyze being cancelled.
Will need to check on that.
>> Will push shortly with the nit-pick fixes you requested.
>
> Cool.
Done.
I will be checking in on the buildfarm, but if it starts causing
problems while I'm, say, sleeping -- I won't be offended if someone
else reverts 7e3da1c4737fd6582e12c80983987e4d2cbc1d17.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On 2016-05-06 19:43:24 -0500, Kevin Grittner wrote:
>> It's disappointing that I am not getting more consistent numbers,
>> but NUMA can be hard to manage that way.
>
> FWIW, in my experience, unless you disable autovacuum (or rather
> auto-analyze), the effects from non-predicable analyze runs with
> long-running snapshots are worse. I mean the numa effects suck, but in
> r/w workload effects of analyze are often much worse.
Hm. But the benefits of the patch are not there if autovacuum is
off. I'm gonna need to ponder the best way to test given all that.
> That comment reminds me of a question I had: Did you consider the effect
> of this patch on analyze? It uses a snapshot, and by memory you've not
> built in a defense against analyze being cancelled.
Will need to check on that.
>> Will push shortly with the nit-pick fixes you requested.
>
> Cool.
Done.
I will be checking in on the buildfarm, but if it starts causing
problems while I'm, say, sleeping -- I won't be offended if someone
else reverts 7e3da1c4737fd6582e12c80983987e4d2cbc1d17.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-committers по дате отправления: