On L, 2005-09-24 at 19:32 -0500, Jim C. Nasby wrote:
> On Sat, Sep 24, 2005 at 07:21:19PM -0400, Tom Lane wrote:
> > > Of course maybe a better question is why we even limit based on the
> > > number of relations...
> >
> > Shared memory is fixed-size.
>
> True, but can't the fixed memory require
Jim C. Nasby wrote:
> On Sat, Sep 24, 2005 at 07:21:19PM -0400, Tom Lane wrote:
> > > Of course maybe a better question is why we even limit based on the
> > > number of relations...
> >
> > Shared memory is fixed-size.
>
> True, but can't the fixed memory required per-relation just be shared
> w
On Sat, Sep 24, 2005 at 07:21:19PM -0400, Tom Lane wrote:
> > Of course maybe a better question is why we even limit based on the
> > number of relations...
>
> Shared memory is fixed-size.
True, but can't the fixed memory required per-relation just be shared
with the fixed memory used to store f
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Rather than keeping track of which relation was last used (presumably
> everytime something hits the FSM), wouldn't it make more sense to just
> drop the relation with the smallest amount of free space in the map?
Why? That certainly wouldn't be cheape
Jim C. Nasby wrote:
> Per http://lnk.nu/developer.postgresql.org/43b.c:
>
> * The number of distinct relations tracked is limited by a configuration
> * variable (MaxFSMRelations). When this would be exceeded, we discard the
> * least recently used relation. A doubly-linked list with move-to-
Per http://lnk.nu/developer.postgresql.org/43b.c:
* The number of distinct relations tracked is limited by a configuration
* variable (MaxFSMRelations). When this would be exceeded, we discard the
* least recently used relation. A doubly-linked list with move-to-front
* behavior keeps track
