Browne
Sent: Wednesday, October 08, 2003 6:22 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
In the last exciting episode, [EMAIL PROTECTED] ("Chris White
(cjwhite)") wrote:
> BTW, the connection I shutdown, had not read, written or deleted any
> large obje
In the last exciting episode, [EMAIL PROTECTED] ("Chris White (cjwhite)") wrote:
> BTW, the connection I shutdown, had not read, written or deleted any
> large objects. It had read and written to other tables. This is causing
> me concern as I am using a thread pool to provide access to the data in
7;Tom Lane'
Cc: 'Robert Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
Tom,
I have found that vacuum only truly gets back all the tuples when there
are no other connections to the database. I found I had a connection to
the database which was doing
#x27;; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Okay now I understand what is going on. I have a second thread which
> is being used to read these objects out of the database to present to
> the us
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Okay now I understand what is going on. I have a second thread which is
> being used to read these objects out of the database to present to the
> user, and because large objects can only be accessed in a transaction
> mode I have not closed t
Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> But as you could see from the prior query \lo_list showed no large
> objects, this was done just prior to the vacuum.
> aesop=# \lo_list
&g
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> But as you could see from the prior query \lo_list showed no large
> objects, this was done just prior to the vacuum.
> aesop=# \lo_list
> Large objects
> ID | Description
> +-
> (0 rows)
> aesop=# vacuum verbose pg_large
To: [EMAIL PROTECTED]
Cc: 'Robert Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Why aren't there any unused tuples?
The "unused" number isn't especially interesting
"Chris White \(cjwhite\)" <[EMAIL PROTECTED]> writes:
> Why aren't there any unused tuples?
The "unused" number isn't especially interesting, it's just the number
of line pointer slots that were once used and aren't at the moment.
At 4 bytes apiece, they aren't costing you anything worth noticing.
ACUUM
Again table has grown by 3 pages.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris White
(cjwhite)
Sent: Thursday, October 02, 2003 4:40 PM
To: 'Tom Lane'
Cc: 'Robert Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Questi
occasion entry doesn't get deleted.
Chris
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 3:46 PM
To: [EMAIL PROTECTED]
Cc: 'Robert Treat'; [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
"Chris White (c
"Chris White (cjwhite)" <[EMAIL PROTECTED]> writes:
> The index has grown by 4 pages and the table has grown by 10 pages. BTW,
> what is a page size? Why is this happening as this is the table that I
> am theoretically keeping the same size by adding/deleting the same
> objects from.
Kinda looks l
PROTECTED] On Behalf Of Robert Treat
Sent: Thursday, October 02, 2003 2:09 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] Question about DB VACUUM
As a starting point, check your free space map settings in the
postgresql.conf. They are low by default in 7.2.x
As a starting point, check your free space map settings in the
postgresql.conf. They are low by default in 7.2.x.
free_space_relations* can safely be bumped to 1000. free_space_pages*
should probably be bumped to something like 5, though you might be
able to determine a better amount be seeing
14 matches
Mail list logo
