"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > ... although to a naive user it's not clear what > is known at vacuum time that the INSERT into the empty table > couldn't have inferred. The fact that the INSERT actually committed. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Simon Riggs wrote: >> We might be able to have bgwriter set hint bits on dirty blocks, > I don't think that works, because the bgwriter has no access to the > catalogs, therefore it cannot examine the page contents. To bgwriter, > pages are opaque. Another issue is that this'd require bgwriter to access the clog SLRU area. I seem to remember worrying that that could lead to low-level deadlocks, though I cannot recall the exact case at the moment. Even without that, it would increase contention for SLRU, which we probably don't want. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Russell Smith <mr-russ@pws.com.au> writes: > Given vacuum must then touch every page, is there a win in only setting > hint bits on pages where vacuum has to do some other work on the page? > As vacuum is causing significant IO load for data that may not be > accessed for some time. Well, if vacuum doesn't do it then some other poor sod will have to. My feeling is that vacuum's purpose in life is to offload maintenance cycles from foreground queries, so we should be happy to have it setting all the hint bits. If Kevin doesn't like the resultant I/O load then he should use the vacuum_cost_delay parameters to dial down vacuum speed. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq