Re: ANALYZE sampling is too good
От | Heikki Linnakangas |
---|---|
Тема | Re: ANALYZE sampling is too good |
Дата | |
Msg-id | 2a291e05-737e-4270-80c5-4df55a57c470@email.android.com обсуждение исходный текст |
Ответ на | Re: ANALYZE sampling is too good (Claudio Freire <klaussfreire@gmail.com>) |
Ответы |
Re: ANALYZE sampling is too good
Re: ANALYZE sampling is too good |
Список | pgsql-hackers |
Claudio Freire <klaussfreire@gmail.com> wrote: >On Mon, Dec 9, 2013 at 8:14 PM, Heikki Linnakangas ><hlinnakangas@vmware.com> wrote: >> I took a stab at using posix_fadvise() in ANALYZE. It turned out to >be very >> easy, patch attached. Your mileage may vary, but I'm seeing a nice >gain from >> this on my laptop. Taking a 30000 page sample of a table with 717717 >pages >> (ie. slightly larger than RAM), ANALYZE takes about 6 seconds without >the >> patch, and less than a second with the patch, with >> effective_io_concurrency=10. If anyone with a good test data set >loaded >> would like to test this and post some numbers, that would be great. > >Kernel version? 3.12, from Debian experimental. With an ssd drive and btrfs filesystem. Admittedly not your average database server setup,so it would be nice to get more reports from others. >I raised this issue on LKML, and, while I got no news on this front, >they might have silently fixed it. I'd have to check the sources >again. Maybe. Or maybe the heuristic read ahead isn't significant/helpful, when you're prefetching with posix_fadvise anyway. I - Heikki
В списке pgsql-hackers по дате отправления: