From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | a(dot)lepikhov(at)postgrespro(dot)ru |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, a(dot)lubennikova(at)postgrespro(dot)ru, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin and sp-gist |
Date: | 2018-11-30 10:10:15 |
Message-ID: | CA+q6zcUmB4i1jQUBc1YU6zppV+u4ADjc05M1f-S3UJGW_0A7Sw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Tue, Jul 31, 2018 at 6:36 AM Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>
> With the consent of Anastasia I will improving this patch further.
> Attachment contains next version of the patch set.
Thank you. I played a bit with this patch, and can confirm visible WAL size
reduction (it's rather obvious, but still). Although, probably due to lack of
my knowledge here, I wonder how does it work when an index is build
concurrently?
> Benchmarks:
> -----------
>
> Test: pgbench -f gin-WAL-test.sql -t 5:
> ---------------------------------------
> master:
> Latency average: 27696.299 ms
> WAL size: 2.66 GB
Does it makes sense to measure latency of the entire script, since it contains
also some preparation work? Of course it still shows the difference between
patched version and master, but probably in a more noisy way.
I'm moving this patch to the next CF.
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2018-11-30 10:18:54 | Re: Speeding up text_position_next with multibyte encodings |
Previous Message | Matsumura, Ryo | 2018-11-30 10:08:31 | RE: [PROPOSAL]a new data type 'bytea' for ECPG |