Hello all,
Executive summary: I have btree index bloat ... I have read all of the
threads I could find on the problem and wanted to confirm that there are no
tuning parameters that could at least reduce the severity of the problem
Detail:
PostgreSQL 8.0.1 on RHEL3
Overall Database Size: 9GB
Size
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 07, 2005 11:53 PM
>
> "David Esposito" <[EMAIL PROTECTED]> writes:
> > Size of "problem" table: 6 million rows
> > Ballpark guess on INSERT/UP
m: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Friday, July 08, 2005 9:52 AM
>
> "David Esposito" <[EMAIL PROTECTED]> writes:
> > Hmm, how are you getting 1/6? The ballpark seems to be
> about 50% or more for
> > those first 4 ...
>
> Ooops, I got con
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 12, 2005 10:14 AM
>
> "David Esposito" <[EMAIL PROTECTED]> writes:
> > As promised, here are two runs of VACUUM VERBOSE on the
> problem table ...
> > The
psed 1200.48 sec.
INFO: analyzing "patronmail.campaign_email"
INFO: "campaign_email": scanned 3000 of 93960 pages, containing 178601 live
rows and 4 dead rows; 3000 rows in sample, 5593783 estimated total rows
> -----Original Message-
> From: Tom Lane [mailto:[EMAI
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 12, 2005 12:26 PM
>
> "David Esposito" <[EMAIL PROTECTED]> writes:
> > As promised, here are two runs of VACUUM VERBOSE on the
> problem table ...
>
> BT
: I was able to cause this same behavior if I did
the following:
psql template1
BEGIN;
SELECT COUNT(*) FROM pg_database;
ROLLBACK;
\q
FYI, I'm using the 8.0.1 RPM build for RHEL3 (2PGDG)
-dave
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tues
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 13, 2005 2:10 PM
> To: David Esposito
>
> Plain VACUUM doesn't try very hard to shorten the table physically, so
> that's not surprising either. But the internal free
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 13, 2005 3:45 PM
>
> Hmm, this is preferentially touching stuff near the right end of the
> index, ie, it's going to bloat the pages associated with higher keys.
> As I understand your usage of these
This week is looking busy for me but hopefully I'll be able to play around
with various vacuuming frequencies for this table ...
Thanks for all of your help; I'll report on my progress
-Dave
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 13, 2005
Executive summary: We just did a cutover from a RedHat 8.0 box to a RedHat
Enterprise Linux 3 box and we're seeing a lot more swapping on the new box
than we ever did on the old box ... this is killing performance ...
Background:
Old Box:
RedHat 8.0
2GB Memory
Dual PIII 60
hould
I set the effective_cache_size to assume that the remaining 1.5 GB of
physical memory is being allocated for the file cache by the kernel?
Thanks,
Dave
> -Original Message-
> From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 06, 2004 10:39 AM
> To:
I just tried installing Postgres 8.1.4 (RPMs from postgresql.org web site)
on a clean RHEL4 Update 2 machine that had SELinux enabled.
When I created a /etc/sysconfig/pgsql/postgresql config file with
PGDATA=/data/pgdata
I was unable to get the start script (/etc/init.d/postgresql) to populate
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
>
> The default selinux policy prevents postgres from writing anywhere
> except under /var/lib/pgsql. If you want a nondefault PGDATA location
> then you have to tweak the policy.
>
It's not that simple ... if I su to post
14 matches
Mail list logo
