Thread: Insert only tables and vacuum performance

Insert only tables and vacuum performance

From
Joseph Shraibman
Date:
I have a table that is never updated, only INSERTED into. Is there a way
I can prevent vacuum wasting time on this table besides vacuuming each
table in the db by itself and omitting this table?

How feasable would it be to have a marker somewhere in pg that is
"updated since last vacuum" that would be cleared when vacuum runs, and
if set vacuum will ignore that table?

Re: Insert only tables and vacuum performance

From
Joseph Shraibman
Date:
Joseph Shraibman wrote:
> I have a table that is never updated, only INSERTED into. Is there a way
> I can prevent vacuum wasting time on this table besides vacuuming each
> table in the db by itself and omitting this table?
>
> How feasable would it be to have a marker somewhere in pg that is
> "updated since last vacuum" that would be cleared when vacuum runs, and
> if set vacuum will ignore that table?

Or even better an offset into the datatable for the earliest deleted
row, so if you have a table where you update the row shortly after
insert and then never touch it vacuum can skip most of the table
(inserts are done at the end of the table, right?)

Re: Insert only tables and vacuum performance

From
Rod Taylor
Date:
> Or even better an offset into the datatable for the earliest deleted
> row, so if you have a table where you update the row shortly after
> insert and then never touch it vacuum can skip most of the table
> (inserts are done at the end of the table, right?)

Inserts are done at the end of the table as a last resort. But anyway,
how do you handle a rolled back insert?



Re: Insert only tables and vacuum performance

From
Joseph Shraibman
Date:
Rod Taylor wrote:
>>Or even better an offset into the datatable for the earliest deleted
>>row, so if you have a table where you update the row shortly after
>>insert and then never touch it vacuum can skip most of the table
>>(inserts are done at the end of the table, right?)
>
>
> Inserts are done at the end of the table as a last resort.

But if most of the table is never updated then the inserts would tend to
be at the end, right?

> But anyway,
> how do you handle a rolled back insert?
>
It is considered like a deleted row to be vacuumed.

Re: Insert only tables and vacuum performance

From
Tom Lane
Date:
Joseph Shraibman <jks@selectacast.net> writes:
> I have a table that is never updated, only INSERTED into. Is there a way
> I can prevent vacuum wasting time on this table

What makes you think vacuum is wasting much time on this table?  AFAICS
it will only update any unfixed hint bits ...

            regards, tom lane

Re: Insert only tables and vacuum performance

From
Joseph Shraibman
Date:
Tom Lane wrote:
> Joseph Shraibman <jks@selectacast.net> writes:
>
>>I have a table that is never updated, only INSERTED into. Is there a way
>>I can prevent vacuum wasting time on this table
>
>
> What makes you think vacuum is wasting much time on this table?  AFAICS
> it will only update any unfixed hint bits ...
>
>             regards, tom lane

INFO:  "elog": found 0 removable, 12869411 nonremovable row versions in
196195 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 5 unused item pointers.
0 pages are entirely empty.
CPU 31.61s/4.53u sec elapsed 1096.83 sec.

It took 1096.83 seconds, and what did it accomplish?  And what are hint
bits?

Re: Insert only tables and vacuum performance

From
Tom Lane
Date:
Joseph Shraibman <jks@selectacast.net> writes:
> INFO:  "elog": found 0 removable, 12869411 nonremovable row versions in
> 196195 pages
> DETAIL:  0 dead row versions cannot be removed yet.
> There were 5 unused item pointers.
> 0 pages are entirely empty.
> CPU 31.61s/4.53u sec elapsed 1096.83 sec.

Hmm.  These numbers suggest that your disk subsystem's bandwidth is
only about 1.4 Mbytes/sec.  Was there a lot else going on?

            regards, tom lane