Re: I/O on select count(*)
От | Alvaro Herrera |
---|---|
Тема | Re: I/O on select count(*) |
Дата | |
Msg-id | 20080515154932.GB8221@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: I/O on select count(*) ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Ответы |
Re: I/O on select count(*)
|
Список | pgsql-performance |
Heikki Linnakangas escribió: > Alvaro Herrera wrote: >> The problem is that the bgwriter does not understand about the content >> of the pages it is writing -- they're opaque pages for all it knows. So >> it cannot touch the hint bits. > > We know what kind of a relation we're dealing with in ReadBuffer, so we > could add a flag to BufferDesc to mark heap pages. Hmm, I was thinking that it would need access to the catalogs to know where the tuples are, but that's certainly not true, so perhaps it could be made to work. >> If we had the bitmask in a separate map fork, this could be cheap. > > I don't buy that. The point of a hint bit is that it's right there along > with the tuple you're looking at. If you have to look at a separate > buffer, you might as well just look at clog. True -- I was confusing this with the idea of having the tuple MVCC header (xmin, xmax, etc) in a separate fork, which would make the idea of index-only scans more feasible at the expense of seqscans. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-performance по дате отправления: