I have never heard that stopping a vacuum is problematic... I have had
to do this many times in the past without any adverse affects. Is there
some sort of documentation which elaborates on this issue?
For the record, I did a VACUUM ANALYZE, not FULL. Now that I think
about it, I probably should have used VERBOSE to see what is happening.
Nothing else was accessing the database, so no process had a lock on
the table.
Tom, regarding insufficient patience: are you suggesting that it is
normal for a vacuum of a table this size to take more than two days
under these circumstances? maintenance_work_mem is 16384.
Joshua: I'm copying the data to a new table right now, I'll see how that
goes.
Alvaro: The cluster suggestion probably won't help in my case since data
in the table should already be naturally ordered by date.
Mike
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> At this point, you are in a world of hurt :). If you stop a vacuum you
>> have created a huge mess of dead rows in that table.
>
> Only if it was a vacuum full, which he didn't mention having tried.
>
> I'm kinda wondering whether the vacuum and reindex did anything at all,
> or were blocked by some other process holding a lock on the table.
> If they weren't blocked, then the problem is insufficient patience,
> possibly combined with insufficient maintenance_work_mem.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
