On Thu, 2004-10-28 at 12:31, Tom Lane wrote: > Josh Berkus <[EMAIL PROTECTED]> writes: > >> One drawback to this is that it would require an additional lseek per table > >> while planning, but that doesn't seem like a huge penalty. > > > Hmmm ... would the additional lseek take longer for larger tables, or would it > > be a fixed cost? > > Should be pretty much a fixed cost: one kernel call per table.
Is this something that the bgwriter could periodically do and share the data? Possibly in the future it could even force a function or prepared statement recompile if the data has changed significantly? ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
