From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Slow count(*) again... |
Date: | 2010-10-13 11:42:00 |
Message-ID: | 4CB59B08.6030900@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 13/10/2010 12:38 AM, Jesper Krogh wrote:
> If some clever postgres hacker could teach postgres to allocate blocks
> using posix_fallocate in quite large batches, say .. something like:
> fallocate(min(current_relation_size *0.1,1073741824))
There doesn't seem to be any use of posix_fallocate in the sources, at
least according to git grep. The patch that introduced posix_fadvise use
apparently had posix_fallocate in it, but that use appears to have been
removed down the track.
It's worth noting that posix_fallocate sucks if your file system doesn't
intelligent support for it. IIRC it's horrible on ext3, where it can
take a while to return while it allocates (and IIRC zeroes!) all those
blocks. This may be part of why it's not used. In past testing with
posix_fallocate for other tools I've also found rather mixed performance
results - it can slow things down rather than speed them up, depending
on the file system in use and all sorts of other factors.
If Pg was to use posix_fallocate, it'd probably need control over it on
a per-tablespace basis.
--
Craig Ringer
Tech-related writing at http://soapyfrogs.blogspot.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2010-10-13 12:11:05 | How to reliably detect if it's a promoting standby |
Previous Message | Andrew Dunstan | 2010-10-13 11:33:58 | Re: WIP: extensible enums |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-10-13 12:12:19 | Re: Slow count(*) again... |
Previous Message | Vitalii Tymchyshyn | 2010-10-13 10:54:19 | Re: Slow count(*) again... |