Skip site navigation (1) Skip section navigation (2)

Re: posix_fadvise v22

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Greg Smith" <gsmith(at)gregsmith(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "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 22:36:31
Message-ID: 603c8f070901021436v71f10188g1d747b493c89f2f5@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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.

Unfortunately I don't have anything useful.  I took the skewed TPC-H
data that Lawrence Ramon posted and created a table based on lineitem
using something along the lines of:

SELECT *, g FROM lineitem, generate_series(1,8) AS g;

Then I made an index on one of the columns and ran some queries that
ended up being planned as bitmap index scans.  The disk seemed to be
doing its thing, but it didn't do it's thing any faster when I changed
effective_io_concurrency to 4 (in fact there might have been a small
slowdown but I didn't take the time to measure carefully, so I can't
refute the null hypothesis).

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Joe ConwayDate: 2009-01-02 22:39:20
Subject: Re: dblink vs SQL/MED
Previous:From: Robert HaasDate: 2009-01-02 21:43:40
Subject: Re: Significantly larger toast tables on 8.4?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group