Re: cpu_tuple_cost - Mailing list pgsql-performance

From Greg Stark
Subject Re: cpu_tuple_cost
Date
Msg-id 87psxzjrxl.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: cpu_tuple_cost  (Josh Berkus <josh@agliodbs.com>)
List pgsql-performance
Josh Berkus <josh@agliodbs.com> writes:

> Although I can point out that you left out the fact that the disk needs to do
> a seek to find the beginning of the seq scan area, and even then some file
> fragmentation is possible.   Finally, I've never seen PostgreSQL manage more
> than 70% of the maximum read rate, and in most cases more like 30%.

Hm. I just did a quick test. It wasn't really long enough to get a good
estimate, but it seemed to reach about 30MB/s on this drive that's only
capable of 40-50MB/s depending on the location on the platters.

That's true though, some of my calculated 25% random seeks could be caused by
fragmentation. But it seems like that would be a small part.

> > So what's going on with the empirically derived value of 4?
>
> It's not empirically derived; it's a value we plug into an
> internal-to-postgresql formula.

I thought Tom said he got the value by doing empirical tests.

--
greg

pgsql-performance by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: Speeding up select distinct
Next
From: "Rodrigo Moreno"
Date:
Subject: Help to find out problem with joined tables