Discarding relations from FSM

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, Pennsylvania 19073

"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, Pennsylvania 19073

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>