Re: insert/update performance

From: Jinhua Luo <luajit(dot)io(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: insert/update performance
Date: 2016-01-27 06:04:33
Message-ID: CAAc9rOywTRm4CSAGST8w5q5xqou2HX7E+r1AL8poBPprb1PL3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ok, I found the vaccum output is correct.

I check the codes of lazy_scan_heap(), the rows to be removed are
reported in two parts, one is return of heap_page_prune(), the other
is ItemIdIsDead() when scanning the page.

After scanning all pages of the relation, those rows would be clean up in:

if (vacrelstats->num_dead_tuples > 0) {
...
lazy_vacuum_heap()
...
}

It would then output
> INFO: "test": removed 6 row versions in 1 pages

The number of rows is correct.

But what kind of rows would satisfy heap_page_prune() and what would not?

In my case all updates are doing the same thing (there is no HOT
updates, obviously), but why some updated rows are reported by
heap_page_prune() but the others are not? And it's also a random
issue. That means sometimes heap_page_prune() would report all
removable rows, and sometimes it reports no rows.

Regards,
Jinhua Luo

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-01-27 07:06:13 Re: Why format() adds double quote?
Previous Message Kouhei Kaigai 2016-01-27 05:52:53 Re: CustomScan under the Gather node?