limiting hint bit I/O
От | Robert Haas |
---|---|
Тема | limiting hint bit I/O |
Дата | |
Msg-id | AANLkTik5QzR8wTs0MqCWwmNp-qHGrdKY5Av5aOB7W4Dp@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: limiting hint bit I/O
|
Список | pgsql-hackers |
I whipped up the attached patch tonight. It's pretty quick and dirty, so it's possible I've missed something, but the intent is to suppress writing of hint bits by buffers allocating backends, and by checkpoints, and write them only from the background writer cleaning scan. It therefore should (and does) avoid the problem that the first scan of a relation after a bulk load is much slower than subsequent scans. I used this test case: create table s as select g, random()::text||random()::text||random()::text||random()::text from generate_series(1,1000000) g; I didn't do any special configuration, so this was large enough to not fit in shared_buffers, but small enough to fit in the OS cache. Then I did this repeatedly: select sum(1) from s; Without the patch, the first run took 1602 ms, and subsequent runs took 207-216 ms. With the patch, the first run took 270 ms, and subsequent runs declined very, very slowly. I got bored after getting down into the 240 ms range and ran VACUUM FREEZE, after which times dropped to about 197 ms. (This also happens without the patch - VACUUM FREEZE seems to speed things up a bit more than just setting all the hint bits.) I find these results pretty depressing. Obviously, the ~6x speedup on the first run is great, but even after many runs subsequent runs it was still 10-15% slower. Certainly, for some people this patch might be an improvement, but on the whole I can't see applying it, unless someone can spot something I've done wrong that casts a different light on the situation. I am a little bit at a loss to explain how I'm getting these results when others posted results that appeared to show hint bits making very little difference. Any insights appreciated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: