Re: POC: Cache data in GetSnapshotData()
От | Mithun Cy |
---|---|
Тема | Re: POC: Cache data in GetSnapshotData() |
Дата | |
Msg-id | CAD__Oug=HXsGTfSUb1Gns0yMCzScaBmORmZuhi5iErAkXTSdYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC: Cache data in GetSnapshotData() (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: POC: Cache data in GetSnapshotData()
|
Список | pgsql-hackers |
On Sat, Jan 16, 2016 at 10:23 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
I also did some read-only perf tests.
Non-Default Settings.
================
scale_factor=300.
./postgres -c shared_buffers=16GB -N 200 -c min_wal_size=15GB -c max_wal_size=20GB -c checkpoint_timeout=900 -c maintenance_work_mem=1GB -c checkpoint_completion_target=0.9
>On Fri, Jan 15, 2016 at 11:23 AM, Mithun Cy <mithun.cy@enterprisedb.com> wrote:On Mon, Jan 4, 2016 at 2:28 PM, Andres Freund <andres@anarazel.de> wrote:
>> I think at the very least the cache should be protected by a separate
>> lock, and that lock should be acquired with TryLock. I.e. the cache is
>> updated opportunistically. I'd go for an lwlock in the first iteration.>I also think this observation of yours is right and currently that is>okay because we always first check TransactionIdIsCurrentTransactionId().
>+ const uint32 snapshot_cached= 0;
I have fixed all of the issues reported by regress test. Also now when backend try to cache the snapshot we also try to store the self-xid and sub xid, so other backends can use them.
I also did some read-only perf tests.
Non-Default Settings.
================
scale_factor=300.
./postgres -c shared_buffers=16GB -N 200 -c min_wal_size=15GB -c max_wal_size=20GB -c checkpoint_timeout=900 -c maintenance_work_mem=1GB -c checkpoint_completion_target=0.9
./pgbench -c $clients -j $clients -T 300 -M prepared -S postgres
Machine Detail:
cpu : POWER8
cores: 24 (192 with HT).
Clients Base With cached snapshot
1 19653.914409 19926.884664
16 190764.519336 190040.299297
32 339327.881272 354467.445076
48 462632.02493 464767.917813
64 522642.515148 533271.556703
80 515262.813189 513353.962521
But did not see any perf improvement. Will continue testing the same.
--
Вложения
В списке pgsql-hackers по дате отправления: