Thread: Discarding relations from FSM
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 beexceeded, we discard the* least recently used relation. A doubly-linked list with move-to-front* behavior keeps trackof which relation is least recently used. 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? Of course maybe a better question is why we even limit based on the number of relations... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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-front > * behavior keeps track of which relation is least recently used. > > 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? The one with the smallest amount of free space might be the one we want to vacuum next, so perhaps it will be added to very soon. The _usage_ of the free space is a much better indicator. > Of course maybe a better question is why we even limit based on the > number of relations... Limited shared memory. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
"Jim C. Nasby" <jnasby@pervasive.com> 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 cheaper to track.
> Of course maybe a better question is why we even limit based on the
> number of relations...
Shared memory is fixed-size.
regards, tom lane
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 free pages? Though, the idea mentioned recently of just using one shared memory segment for everything and allocating dynamically within that probably makes more sense... -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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 > with the fixed memory used to store free pages? The assumption is that the admin wants to control the allotment of memory, and doesn't want it to shift based on (perhaps temporary) load. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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 required per-relation just be shared > with the fixed memory used to store free pages? > > Though, the idea mentioned recently of just using one shared memory > segment for everything and allocating dynamically within that probably > makes more sense... I guess that communicating those changes to all running backends may be expensive. -- Hannu Krosing <hannu@skype.net>