From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Support for REINDEX CONCURRENTLY |
Date: | 2013-06-18 15:37:20 |
Message-ID: | CAHGQGwHNC1s8Xe2Mnwz0fpdSW4R6NEJu92AHK90YsBSukMisXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 18, 2013 at 9:54 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Hi,
>
> On 2013-06-18 11:35:10 +0200, Andres Freund wrote:
>> Going to do some performance tests now.
>
> Ok, so ran the worst case load I could think of and didn't notice
> any relevant performance changes.
>
> The test I ran was:
>
> CREATE TABLE test_toast(id serial primary key, data text);
> ALTER TABLE test_toast ALTER COLUMN data SET STORAGE external;
> INSERT INTO test_toast(data) SELECT repeat('a', 8000) FROM generate_series(1, 200000);
> VACUUM FREEZE test_toast;
>
> And then with that:
> \setrandom id 1 200000
> SELECT id, substring(data, 1, 10) FROM test_toast WHERE id = :id;
>
> Which should really stress the potentially added overhead since we're
> doing many toast accesses, but always only fetch one chunk.
Sounds really good!
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-06-18 16:09:59 | Re: Patch for fast gin cache performance improvement |
Previous Message | Fujii Masao | 2013-06-18 15:36:28 | Re: Support for REINDEX CONCURRENTLY |