> -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
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
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
> -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
> -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
: 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: 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
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 10:14 AM
>
> "David Esposito" <[EMAIL PROTECTED]> writes:
> > As promised, here are two runs of VACUUM VERBOSE on the
> problem table ...
> > The
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: Thursday, July 07, 2005 11:53 PM
>
> "David Esposito" <[EMAIL PROTECTED]> writes:
> > Size of "problem" table: 6 million rows
> > Ballpark guess on INSERT/UP
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
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:
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
14 matches
Mail list logo
