On Thu, 2004-10-28 at 12:31, Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> 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?
