Re: ANALYZE sampling is too good - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: ANALYZE sampling is too good
Date
Msg-id 2a291e05-737e-4270-80c5-4df55a57c470@email.android.com
Whole thread Raw
In response to Re: ANALYZE sampling is too good  (Claudio Freire <klaussfreire@gmail.com>)
Responses Re: ANALYZE sampling is too good
Re: ANALYZE sampling is too good
List 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 by date:

Previous
From: Claudio Freire
Date:
Subject: Re: ANALYZE sampling is too good
Next
From: Claudio Freire
Date:
Subject: Re: ANALYZE sampling is too good