Re: [PATCHES] A way to let Vacuum warn if FSM settings are low.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] A way to let Vacuum warn if FSM settings are low.
Date: 2005-02-24 00:31:05
Message-ID: 23726.1109205065@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-patches

Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> writes:
> + if (needed > MaxFSMPages)
> + ereport(WARNING,
> + (errmsg("max_fsm_pages(%d) is smaller than total pages needed(%.0f)",
> + MaxFSMPages, needed)));

An unconditional WARNING seems a bit strong to me for a case that is not
necessarily wrong. Depending on the needs of the installation, this
might be a perfectly acceptable situation --- for example if you have
lots of large read-mostly tables.

On the other side of the coin, the test could pass (ie no warning) in
situations where in fact MaxFSMPages is too small, because what we are
comparing it to is the number of pages requested for relations that are
being tracked. If MaxFSMRelations is too small then we can't really
tell whether MaxFSMPages is adequate.

> + if (numRels > MaxFSMRelations)
> + ereport(WARNING,
> + (errmsg("max_fsm_relations(%d) is smaller than the number of relations (%d)",
> + MaxFSMRelations, numRels)));

This part is just plain dead code, since it's not possible for numRels
to exceed MaxFSMRelations.

I think it might be useful to warn when numRels == MaxFSMRelations,
since if you don't have even one spare fsmrel slot then you probably
have too few (it's unlikely you got it on the nose). But I don't know
how to produce a warning about MaxFSMPages that's worth anything.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Lonni J Friedman 2005-02-24 00:45:04 multiple runs of the same query cause out of memory - WAS [Re: capturing/viewing sort_mem utilization on a per query basis]
Previous Message Tom Lane 2005-02-24 00:19:15 Re: view/pgpgsql functions bug

Browse pgsql-patches by date

  From Date Subject
Next Message John Hansen 2005-02-24 00:37:48 Re: optimize md5_text
Previous Message Tom Lane 2005-02-23 23:58:47 Re: invalid multibyte character for locale