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 по дате отправления: