Tom Lane wrote: > * We also need to think harder about when to invoke the page pruning > code. As the patch stands, if you set a breakpoint at > heap_page_prune_opt it'll seem to be hit constantly (eg, once for every > system catalog probe), which seems uselessly often. And yet it also > seems not often enough, because one thing I found out real fast is that > the "prune if free space < 1.2 average tuple size" heuristic fails badly > when you look at queries that execute multiple updates within the same > heap page. We only prune when we first pin a particular target page, > and so the additional updates don't afford another chance to see if it's > time to prune. > > I'd like to see if we can arrange to only do pruning when reading a page > that is known to be an update target (ie, never during plain SELECTs); > I suspect this would be relatively easy with some executor and perhaps > planner changes. But that only fixes the first half of the gripe above; > I'm not at all sure what to do about the multiple-updates-per-page > issue.
If we only prune on an update (or insert) why not just do prune every time? I figure the prune/defrag has to be lighter than the update/insert itself. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
