On 4 Sep 2013 20:46, "Heikki Linnakangas" wrote:
>
> One fairly simple thing we could do is to teach catcache.c to resize the
caches. Then we could make the initial size of all the syscaches much
smaller. At the moment, we use fairly caches for catalogs like pg_enum (256
entries) and pg_usermappi
On 05.09.2013 17:22, Tom Lane wrote:
Heikki Linnakangas writes:
I ran pgbench for ten seconds, and printed the number of tuples in each
catcache after that:
[ very tiny numbers ]
I find these numbers a bit suspicious. For example, we must have hit at
least 13 different system catalogs, and m
Heikki Linnakangas writes:
> I ran pgbench for ten seconds, and printed the number of tuples in each
> catcache after that:
> [ very tiny numbers ]
I find these numbers a bit suspicious. For example, we must have hit at
least 13 different system catalogs, and more than that many indexes, in
the
On 04.09.2013 23:56, Tom Lane wrote:
Heikki Linnakangas writes:
One fairly simple thing we could do is to teach catcache.c to resize the
caches. Then we could make the initial size of all the syscaches much
smaller.
I think this is attractive for the *other* reason you mention, namely
preserv
Heikki Linnakangas writes:
> One fairly simple thing we could do is to teach catcache.c to resize the
> caches. Then we could make the initial size of all the syscaches much
> smaller.
I think this is attractive for the *other* reason you mention, namely
preserving reasonable performance when a
I received a complaint that each backend consumes a lot of
backend-private memory, even if it's completely idle. "a lot" is of
course very subjective and how much memory is actually used depends
heavily on the application. In this case, the database is fairly small,
but they have 250 connection
