Re: Support for REINDEX CONCURRENTLY
От | Andres Freund |
---|---|
Тема | Re: Support for REINDEX CONCURRENTLY |
Дата | |
Msg-id | 20130618125452.GF5646@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Support for REINDEX CONCURRENTLY (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Support for REINDEX CONCURRENTLY
|
Список | pgsql-hackers |
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. One other thing: Your latest patch forgot to adjust rules.out, so make check didn't pass... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: