Hi, probably this is a very frequenfly question... I read archivies of
this list but I didn't found a finally solution for this aspect. I'll
explain my situation.
PSQL version 8.1.3
configuration of fsm,etcc default
autovacuum and statistics activated
22 daemons that have a persistent connection
Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
> 22 daemons that have a persistent connection to this database(all
> connection are in "idle"(no transaction opened).
You may think that, but you are wrong.
> INFO: "cliente": found 0 removable, 29931 nonremovable row versions in 559
> pages
> DETA
Are there open transactions on the table in question? We had the same
issue. A 100K row table was so bloated that the system thought there was
1M rows. We had many transaction that we noticed in TOP, but since
we could not track down which process or user was holding the table we had
to restart
Hi, Tom and Matteo,
Tom Lane wrote:
> Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
>> 22 daemons that have a persistent connection to this database(all
>> connection are in "idle"(no transaction opened).
>
> You may think that, but you are wrong.
>
>> INFO: "cliente": found 0 removable, 29931
Hi,
I've been looking at the results from the pg_statio* tables, to
view the impact of increasing the shared buffers to increase
performance.
As expected, increasing from the default by a factor of 10~20
moves table/index disk blocks reads to cache hits, but the
overall service time of my test pa
On Fri, Sep 01, 2006 at 10:43:30AM -0400, Tom Lane wrote:
> Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
> > 22 daemons that have a persistent connection to this database(all
> > connection are in "idle"(no transaction opened).
>
> You may think that, but you are wrong.
Ok. I stopped all clients.
Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
> Ok. I stopped all clients. No connections to this database.
When you say "this database", do you mean the whole postmaster cluster,
or just the one database? Open transactions in other databases of the
same cluster can be a problem.
On 01 Sep 2006 19:00:52 +0200, Guillaume Cottenceau <[EMAIL PROTECTED]> wrote:
Hi,
I've been looking at the results from the pg_statio* tables, to
view the impact of increasing the shared buffers to increase
performance.
I think 'shared buffers' is one of the most overrated settings from a
pe
On Fri, 2006-09-01 at 12:28, Matteo Sgalaberni wrote:
> On Fri, Sep 01, 2006 at 10:43:30AM -0400, Tom Lane wrote:
> > Matteo Sgalaberni <[EMAIL PROTECTED]> writes:
> > > 22 daemons that have a persistent connection to this database(all
> > > connection are in "idle"(no transaction opened).
> >
> >
Guillaume
1G is really not a significant amount of memory these days,
That said 6-10% of available memory should be given to an 8.0 or
older version of postgresql
Newer versions work better around 25%
I'm not sure what you mean by mechanically removed from effective_cache
effective cache i
On 1-Sep-06, at 3:49 PM, Merlin Moncure wrote:
On 01 Sep 2006 19:00:52 +0200, Guillaume Cottenceau <[EMAIL PROTECTED]> wrote:
Hi,
I've been looking at the results from the pg_statio* tables, to
view the impact of increasing the shared buffers to increase
performance.
I think 'shared buffer
I think 'shared buffers' is one of the most overrated settings from a
performance standpoint. however you must ensure there is enough for
things the server does besides caching. It used to be a bigger deal
than it is in modern versionf of postgresql modern operating systems.
Previous to 8.1 I
12 matches
Mail list logo
