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

Reply via email to