Martijn van Oosterhout wrote:
> On Thu, Apr 26, 2007 at 12:13:13AM +0200, Listmail wrote:
> > VACUUM FULL is slow because it plays with the indexes...
> > CLUSTER is slow because it has to order the rows...
>
> And:
> VACUUM FULL has to seek/read/write all over the disk to get it's job
> d
On Thu, Apr 26, 2007 at 12:13:13AM +0200, Listmail wrote:
> VACUUM FULL is slow because it plays with the indexes...
> CLUSTER is slow because it has to order the rows...
And:
VACUUM FULL has to seek/read/write all over the disk to get it's job
done.
CLUSTER can scan through the table
On Thu, 2007-04-26 at 00:13 +0200, Listmail wrote:
> By the way, about indexes :
>
> When you have a small table (say, for a website, maybe a few
> tens of
> megabytes max...) reindexing it takes just a few seconds, maybe
> 10-20
> seconds.
> It could be interesting, performanc
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Steve Crawford wrote:
>>> Am I reading that what it actually does is to thrash around keeping
>>> indexes unnecessarily updated, bloating them in the process?
>
>> Yes.
>
> Just for the record, it's not "unnecessary". The point of t
I don't see a way to remove the old index entries before inserting new
ones without creating a window where the index and table will be
inconsistent if vacuum fails.
VACUUM FULL is slow because it plays with the indexes...
CLUSTER is slow because it has to order the rows...
M
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Steve Crawford wrote:
>> Am I reading that what it actually does is to thrash around keeping
>> indexes unnecessarily updated, bloating them in the process?
> Yes.
Just for the record, it's not "unnecessary". The point of that is to
not leave a corrup
Steve Crawford wrote:
> So my mental-model is utterly and completely wrong. My assumption was
> that since a full vacuum requires an access exclusive lock, it would do
> the intelligent and efficient thing which would be to first compact the
> table and then recreate the indexes.
Right, it doesn'
Martijn van Oosterhout wrote:
> On Wed, Apr 25, 2007 at 09:36:35AM -0700, Steve Crawford wrote:
>> Hmmm, why would cluster be faster?
>
> Basically, vacuum full moves tuples from the end to the beginning of a
> table so it can compact the table. In the process it needs to update
> all the indexes
On Wed, Apr 25, 2007 at 09:36:35AM -0700, Steve Crawford wrote:
> Hmmm, why would cluster be faster?
Basically, vacuum full moves tuples from the end to the beginning of a
table so it can compact the table. In the process it needs to update
all the indexes too. So you save heap space but it tends
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I wonder, though, if you set maintenance_work_mem too high and are
> causing the OS to swap?
AFAIR, vacuum full pays no attention to maintenance_work_mem anyway.
If the data it needs doesn't fit in memory, you lose ...
regards,
> You could try CLUSTER instead of VACUUM FULL, as I think it should be
> faster. And the indexes will be devoid of any bloat, which will be a
> nice side effect.
>
> I wonder, though, if you set maintenance_work_mem too high and are
> causing the OS to swap?
>
Hmmm, why would cluster be faster
Steve Crawford wrote:
> I'm in the process of archiving data on one of my PG machines. After
> backing up the data, I delete the old records and then run a "vacuum
> full" on each table.
>
> I'm vacuuming the first table now and it is taking much longer than I
> expected (I'm now past the 2-hour m
I'm in the process of archiving data on one of my PG machines. After
backing up the data, I delete the old records and then run a "vacuum
full" on each table.
I'm vacuuming the first table now and it is taking much longer than I
expected (I'm now past the 2-hour mark). Some info:
Version: 8.1.2
O
13 matches
Mail list logo
