Re: posix_fadvise v22

From: "Greg Stark" <stark(at)enterprisedb(dot)com>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Greg Smith" <gsmith(at)gregsmith(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: posix_fadvise v22
Date: 2009-01-02 23:02:17
Message-ID: 4136ffa0901021502w78f0611dx63929ac0fbbdc2f4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 2, 2009 at 5:36 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I've got a stack of hardware I can do performance testing of this patch on,
>> what I haven't been able to find time for is setting up any sort of test
>> harness right now. If you or Greg have any benchmark or test program you
>> could suggest that should show off the improvements here, I'd be glad to run
>> it on a bunch of systems and report back--I've already got a stack of
>> candidate ones I ran the earlier tests on to compare results against.
>
> Then I made an index on one of the columns and ran some queries that
> ended up being planned as bitmap index scans.

Hm, what were those plans? You might want to put the old code back in
explain.c to print the prefetching target to see how well it's doing.

The queries I ran to test it tended to look like this kind of thing,
where r was a column filled with random values. If it's clustered
there will be hardly any benefit as even random i/o would be
prefetched by the OS.

select * from h where r = any (array(select
(1+random()*2000000)::integer from generate_series(1,1000)));

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-01-02 23:09:23 Re: Several tags around PostgreSQL 7.1 broken
Previous Message Martijn van Oosterhout 2009-01-02 22:48:15 Re: Significantly larger toast tables on 8.4?