Re: cpu_tuple_cost

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: cpu_tuple_cost
Дата
Msg-id 87psxzjrxl.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: cpu_tuple_cost  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: "Merlin Moncure"
Дата:
Сообщение: Re: Speeding up select distinct
Следующее
От: "Rodrigo Moreno"
Дата:
Сообщение: Help to find out problem with joined tables