Have you gotten performance numbers on this yet? ---------------------------------------------------------------------------
Gregory Stark wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > > Tom Lane wrote: > > > > > In any case I'd like to see some evidence of significant real-world > > > benefit before adding such a conceptual wart ... > > > > I've asked our testers to do a TPC-C run with and without the > > patch. I'm not expecting it to make a huge difference there, but if you're > > using a big cost delay, it could make quite a difference for such a simple > > thing. > > I think the key here is that it removes the size of the table from the list of > factors that govern the steady-state. Currently as the table grows the maximum > age of the snapshot vacuum uses gets older too which means a greater > percentage of the table is dedicated to dead tuple overhead. (which in turn > means a larger table which means an even greater percentage of dead tuples...) > > With the patch the size of the table is no longer a factor. As long as the > work vacuum has on a given page can keep up with the rate of creating dead > tuples then it won't matter how large the table is. The only factors that > determine the steady state are the rate of creation of dead tuples and the > rate at which vacuum can process them. > > Unfortunately indexes, again, mean that's not entirely true. As the table > grows the indexes will grow as well and that will slow vacuum down. Though > indexes are usually smaller than tables. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org