Re: Initial prefetch performance testing - Mailing list pgsql-hackers

From Ron Mayer
Subject Re: Initial prefetch performance testing
Date
Msg-id 48D804E1.3080802@cheapcomplexdevices.com
Whole thread Raw
In response to Re: Initial prefetch performance testing  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> I'd rather a parameter that expressed things more in terms of
>> measurable quantities [...]
> 
> ...What we're
> dealing with now is an entirely orthogonal property of your system: how many
> concurrent requests can the system handle.

Really?  I'd have thought you'd want to give the OS enough guesses
about the future that it's elevator algorithms for the drive heads
don't keep seeking back-and-forth but rather do as much per sweep
across a device that they can.

> Ironically I'm pretty happy to lose this argument because EDB is interested in
> rolling this into its dynamic tuning module. If there's a consensus -- by my
> count three people have spoken up already which is more than usual -- then
> I'll gladly concede. Anyone object to going back to preread_pages? Or should
> it be prefetch_pages? prefetch_blocks? Something else?

Well - as you pointed out, I'm not on their side of the debate either.
I'm not sure what a relevant measurable parameter would be so I'm not
being too helpful in the conversation either.


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Initial prefetch performance testing
Next
From: Tommy Gildseth
Date:
Subject: Re: [patch] fix dblink security hole