On 5/16/2007 7:47 PM, Don Barthel wrote:
> Jeff:
> 
> Thanks for responding! I have edited out some bits to keep this as
> brief as possible.
> 
>> Shared buffers on the origin or the subscriber? Shared buffers might not
>> matter in this case anyway.
> 
> I upped the shared_buffers on both the origin and subscriber from
> 20,000 to 40,000 then did a reload (not a restart) in Postgres on both
> the origin and the subscriber.

Anything that affects the shared memory configuration in Postgres 
(shared buffers, max number connections, etc.) requires a restart. A 
reload ignores those changes.

> SELECT relname, reltuples, relpages FROM pg_class ORDER BY relpages DESC ;
>              relname             |  reltuples  | relpages
> ---------------------------------+-------------+----------
>  indx_tsearch2a                  |       72559 |    66324
>  indx_tsearch2c                  |       40761 |    44640
>  used_ad                         |      335542 |    38646

Hard to believe that 300MB of data will cause nearly a GB of index 
information ... but then again this is tsearch, which I don't know too 
well. However, I would try to reindx that table and see what's left 
after that.

> 
> (used_ad is the table, the other two are partial indexes.)
> 
> So, my shared_buffers is 40,000 and two of my indexes are bigger than
> that. The total size of all 12 indexes is some 324,000 'relpages'.
> 
> *** Is shared_buffers comparable to 'relpages'? If so, is it practical
> to bump shared_buffers to 325,000? That's just over 2.5GB by my
> calculation - I have 3GB on the machine.

relpages as well as shared buffers are measured in block size, which 
defaults to 8k. So yes, they are comparable. On a 3GB machine (assuming 
this is a dedicated database server) I would start out with 125,000 
shared buffers (roughly one GB).


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #