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 по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: ANALYZE sampling is too good
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: ANALYZE sampling is too good