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

From Heikki Linnakangas
Subject Re: ANALYZE sampling is too good
Date
Msg-id 52A63A7A.6090606@vmware.com
Whole thread Raw
In response to Re: ANALYZE sampling is too good  (Jim Nasby <jim@nasby.net>)
Responses Re: ANALYZE sampling is too good
List pgsql-hackers
On 12/09/2013 11:35 PM, Jim Nasby wrote:
> On 12/8/13 1:49 PM, Heikki Linnakangas wrote:
>> On 12/08/2013 08:14 PM, Greg Stark wrote:
>>> The whole accounts table is 1.2GB and contains 10 million rows. As
>>> expected with rows_per_block set to 1 it reads 240MB of that
>>> containing nearly 2 million rows (and takes nearly 20s -- doing a full
>>> table scan for select count(*) only takes about 5s):
>>
>> One simple thing we could do, without or in addition to changing the
>> algorithm, is to issue posix_fadvise() calls for the blocks we're
>> going to read. It should at least be possible to match the speed of a
>> plain sequential scan that way.
>
> Hrm... maybe it wouldn't be very hard to use async IO here either? I'm
> thinking it wouldn't be very hard to do the stage 2 work in the callback
> routine...

Yeah, other than the fact we have no infrastructure to do asynchronous 
I/O anywhere in the backend. If we had that, then we could easily use it 
here. I doubt it would be much better than posix_fadvising the blocks, 
though.

- Heikki



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?
Next
From: Nigel Heron
Date:
Subject: Re: stats for network traffic WIP