Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4 - Mailing list pgsql-performance

From Gregory Stark
Subject Re: 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4
Date
Msg-id 87vdqd4jyy.fsf@oxford.xeocode.com
Whole thread Raw
In response to 8.4 Performance improvements: was Re: Proposal of tunable fix for scalability of 8.4  ("Jignesh K. Shah" <J.K.Shah@Sun.COM>)
List pgsql-performance
"Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:

> Can we do a vote on which specific performance features we want to test?
>
> Many of the improvements may not be visible through this standard tests so
> feedback on testing methology for those is also appreciated.
> * Visibility map - Reduce Vacuum overhead - (I think I can time vacuum with
> some usage on both databases)

Timing vacuum is kind of pointless -- the only thing that matters is whether
it's "fast enough". But it is worth saying that good benchmarks should include
normal vacuum runs. Benchmarks which don't run long enough to trigger vacuum
aren't realistic.

> * Prefetch IO with posix_fadvice () - Though I am not sure if it is supported
> on UNIX or not (but can be tested by standard tests)

Well clearly this is my favourite :)

AFAIK Opensolaris doesn't implement posix_fadvise() so there's no benefit. It
would be great to hear if you could catch the ear of the right people to get
an implementation committed. Depending on how the i/o scheduler system is
written it might not even be hard -- the Linux implementation of WILLNEED is
all of 20 lines.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's Slony Replication support!

pgsql-performance by date:

Previous
From: "Jignesh K. Shah"
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4
Next
From: Gregory Stark
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4