Re: Seq scans roadmap
От | CK Tan |
---|---|
Тема | Re: Seq scans roadmap |
Дата | |
Msg-id | AD9630BA-9A0F-408C-A7E1-D799722986AC@greenplum.com обсуждение исходный текст |
Ответ на | Re: Seq scans roadmap (Heikki Linnakangas <heikki@enterprisedb.com>) |
Список | pgsql-hackers |
The patch has no effect on scans that do updates. The KillAndReadBuffer routine does not force out a buffer if the dirty bit is set. So updated pages revert to the current performance characteristics. -cktan GreenPlum, Inc. On May 10, 2007, at 5:22 AM, Heikki Linnakangas wrote: > Zeugswetter Andreas ADI SD wrote: >>> In reference to the seq scans roadmap, I have just submitted a >>> patch that addresses some of the concerns. >>> >>> The patch does this: >>> >>> 1. for small relation (smaller than 60% of bufferpool), use the >>> current logic 2. for big relation: >>> - use a ring buffer in heap scan >>> - pin first 12 pages when scan starts >>> - on consumption of every 4-page, read and pin the next 4-page >>> - invalidate used pages of in the scan so they do not force out >>> other useful pages >> A few comments regarding the effects: >> I do not see how this speedup could be caused by readahead, so >> what are >> the effects ? > > I was wondering that as well. We'd really need to test all the > changes separately to see where the improvements are really coming > from. > > Also, that patch doesn't address the VACUUM issue at all. And using > a small fixed size ring with scans that do updates can be > devastating. I'm experimenting with different ring sizes for COPY > at the moment. Too small ring leads to a lot of WAL flushes, it's > basically the same problem we have with VACUUM in CVS HEAD. > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com >
В списке pgsql-hackers по дате отправления: