, April 24, 2004 8:29 PM
To: Shea,Dan [CIS]
Cc: 'Josh Berkus'; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Why will vacuum not end?
On Sat, 24 Apr 2004 15:58:08 -0400, Shea,Dan [CIS] [EMAIL PROTECTED]
wrote:
There were defintely 219,177,133 deletions.
The deletions are most likely from the beginning
On Sun, 25 Apr 2004 09:05:11 -0400, Shea,Dan [CIS] [EMAIL PROTECTED]
wrote:
It is set at max_fsm_pages = 150 .
This might be too low. Your index has ca. 5 M pages, you are going to
delete half of its entries, and what you delete is a contiguous range of
values. So up to 2.5 M index pages
(15 to 30 every
3 to 20 minutes).
Is the vacuum causing this?
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Friday, April 23, 2004 2:48 PM
To: Shea,Dan [CIS]; 'Christopher Kings-Lynne'
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Why will vacuum not end?
Guys
Dan,
Josh, how long should a vacuum take on a 87 GB table with a 39 GB index?
Depends:
-- What's your disk support?
-- VACUUM, VACUUM ANALYZE, or VACUUM FULL?
-- What's your vacuum_mem setting?
-- What are checkpoint and wal settings?
I see alot of activity with transaction logs being
On Sat, 24 Apr 2004 10:45:40 -0400, Shea,Dan [CIS] [EMAIL PROTECTED]
wrote:
[...] 87 GB table with a 39 GB index?
The vacuum keeps redoing the index, but there is no indication as to why it
is doing this.
If VACUUM finds a dead tuple, if does not immediately remove index
entries pointing to
Manfred is indicating the reason it is taking so long is due to the number
of dead tuples in my index and the vacuum_mem setting.
The last delete that I did before starting a vacuum had 219,177,133
deletions.
Dan.
Dan,
Josh, how long should a vacuum take on a 87 GB table with a 39 GB index?
:[EMAIL PROTECTED]
Sent: Saturday, April 24, 2004 1:57 PM
To: Shea,Dan [CIS]
Cc: 'Josh Berkus'; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Why will vacuum not end?
On Sat, 24 Apr 2004 10:45:40 -0400, Shea,Dan [CIS] [EMAIL PROTECTED]
wrote:
[...] 87 GB table with a 39 GB index?
The vacuum keeps redoing
On Sat, 24 Apr 2004 15:48:19 -0400, Shea,Dan [CIS] [EMAIL PROTECTED]
wrote:
Manfred is indicating the reason it is taking so long is due to the number
of dead tuples in my index and the vacuum_mem setting.
nitpicking
Not dead tuples in the index, but dead tuples in the table.
/nitpicking
The
On Sat, 24 Apr 2004 15:58:08 -0400, Shea,Dan [CIS] [EMAIL PROTECTED]
wrote:
There were defintely 219,177,133 deletions.
The deletions are most likely from the beginning, it was based on the
reception_time of the data.
I would rather not use re-index, unless it is faster then using vacuum.
I
Dan,
There were defintely 219,177,133 deletions.
The deletions are most likely from the beginning, it was based on the
reception_time of the data.
You need to run VACUUM more often, I think.Vacuuming out 219 million dead
tuples is going to take a long time no matter how you look at it.
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 9:26 PM
To: Shea,Dan [CIS]
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Why will vacuum not end?
No, but data is constantly being inserted by userid scores. It is
postgres
runnimg the vacuum.
Dan.
Well, inserts create some locks - perhaps
Guys,
Well, inserts create some locks - perhaps that's the problem...
Otherwise, check the pg_locks view to see if you can figure it out.
FWIW, I've had this happen a couple of times, too. Unfortunately, it's
happend in the middle of the day so that I had to cancel the processes and
get
No, but data is constantly being inserted by userid scores. It is postgres
runnimg the vacuum.
Dan.
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 12:02 AM
To: Shea,Dan [CIS]
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Why
: [PERFORM] Why will vacuum not end?
This vacuum is running a marathon. Why will it not end and show me free
space map INFO? We have deleted a lot of data and I would like to be
confident that these deletions will be used as free space, rather than
creating more table files.
Does another postgres
No, but data is constantly being inserted by userid scores. It is postgres
runnimg the vacuum.
Dan.
Well, inserts create some locks - perhaps that's the problem...
Otherwise, check the pg_locks view to see if you can figure it out.
Chris
---(end of
This vacuum is running a marathon. Why will it not end and show me free
space map INFO? We have deleted a lot of data and I would like to be
confident that these deletions will be used as free space, rather than
creating more table files.
Does another postgres query running have a lock on that
16 matches
Mail list logo
