Re: I/O on select count(*)
От
Decibel!
Тема
Re: I/O on select count(*)
Дата
Msg-id
F16DFE65-7DC5-4D5A-9B18-4F6FA070ACD8@decibel.org
Ответ на
Re: I/O on select count(*) (Greg Smith)
Список
Дерево обсуждения
I/O on select count(*) Doug Eck <deck1@yahoo.com>
Re: I/O on select count(*) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: I/O on select count(*) Greg Smith <gsmith@gregsmith.com>
Re: I/O on select count(*) Alvaro Herrera <alvherre@commandprompt.com>
Re: I/O on select count(*) James Mansion <james@mansionfamily.plus.com>
Re: I/O on select count(*) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
Re: I/O on select count(*) Greg Smith <gsmith@gregsmith.com>
Re: I/O on select count(*) "Jan de Visser" <jdevisser@digitalfairway.com>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) Jan de Visser <jdevisser@digitalfairway.com>
Re: I/O on select count(*) Robert Lor <Robert.Lor@Sun.COM>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) Robert Lor <Robert.Lor@Sun.COM>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) "Pavan Deolasee" <pavan.deolasee@gmail.com>
Re: I/O on select count(*) Luke Lonergan <llonergan@greenplum.com>
Re: I/O on select count(*) "Joshua D. Drake" <jd@commandprompt.com>
Re: I/O on select count(*) Tino Wildenhain <tino@wildenhain.de>
Re: I/O on select count(*) Gregory Stark <stark@enterprisedb.com>
Re: I/O on select count(*) Matthew Wakeling <matthew@flymine.org>
Re: I/O on select count(*) Ron Mayer <rm_pg@cheapcomplexdevices.com>
Re: I/O on select count(*) Greg Smith <gsmith@gregsmith.com>
Re: I/O on select count(*) Alvaro Herrera <alvherre@commandprompt.com>
Re: I/O on select count(*) "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: I/O on select count(*) Alvaro Herrera <alvherre@commandprompt.com>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) Matthew Wakeling <matthew@flymine.org>
Re: I/O on select count(*) Alvaro Herrera <alvherre@commandprompt.com>
Re: I/O on select count(*) Greg Smith <gsmith@gregsmith.com>
Re: I/O on select count(*) Simon Riggs <simon@2ndquadrant.com>
Re: I/O on select count(*) Alvaro Herrera <alvherre@commandprompt.com>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) Jeremy Harris <jgh@wizmail.org>
Re: I/O on select count(*) Greg Smith <gsmith@gregsmith.com>
Re: I/O on select count(*) Decibel! <decibel@decibel.org>
Re: I/O on select count(*) Decibel! <decibel@decibel.org>
Re: I/O on select count(*) "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) Simon Riggs <simon@2ndquadrant.com>
Re: I/O on select count(*) Matthew Wakeling <matthew@flymine.org>
Re: I/O on select count(*) Bruce Momjian <bruce@momjian.us>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) Greg Smith <gsmith@gregsmith.com>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) PFC <lists@peufeu.com>
Re: I/O on select count(*) Alvaro Herrera <alvherre@commandprompt.com>
Re: I/O on select count(*) "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: I/O on select count(*) Matthew Wakeling <matthew@flymine.org>
Re: I/O on select count(*) Tom Lane <tgl@sss.pgh.pa.us>
Re: I/O on select count(*) "Heikki Linnakangas" <heikki@enterprisedb.com>
Re: I/O on select count(*) Matthew Wakeling <matthew@flymine.org>
Re: I/O on select count(*) "Merlin Moncure" <mmoncure@gmail.com>
On May 18, 2008, at 1:28 AM, Greg Smith wrote: > I just collected all the good internals information included in > this thread and popped it onto http://wiki.postgresql.org/wiki/ > Hint_Bits where I'll continue to hack away at the text until it's > readable. Thanks to everyone who answered my questions here, > that's good progress toward clearing up a very underdocumented area. > > I note a couple of potential TODO items not on the official list > yet that came up during this discussion: > > -Smooth latency spikes when switching commit log pages by > preallocating cleared pages before they are needed > > -Improve bulk loading by setting "frozen" hint bits for tuple > inserts which occur within the same database transaction as the > creation of the table into which they're being inserted > > Did I miss anything? I think everything brought up falls either > into one of those two or the existing "Consider having the > background writer update the transaction status hint bits..." TODO. Blah, sorry for the double-post, but I just remembered a few things... Did we completely kill the idea of the bg_writer *or some other background process* being responsible for setting all hint-bits on dirty pages before they're written out? Also, Simon and Tom had an idea at PGCon: Don't set hint-bits in the back-end if the page isn't already dirty. We'd likely need some heuristics on this... based on Luke's comments about improved CLOG caching maybe we want to set the bits anyway if the tuples without them set are from old transactions (idea being that pulling those CLOG pages would be pretty expensive). Or better yet; if we have to read a CLOG page off disk, set the bits. This could still potentially be a big disadvantage for data warehouses; though perhaps the way to fix that is recommend a backgrounded vacuum after data load. -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
В списке pgsql-performance по дате отправления