Re: New gist vacuum.

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Костя Кузнецов <chapaev28(at)ya(dot)ru>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: New gist vacuum.
Date: 2017-12-30 09:18:02
Message-ID: C6DBDFBF-7D5D-4FFE-8D42-5FEC4481EE77@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Hi!

> 28 дек. 2017 г., в 16:37, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> написал(а):
> Here is new version of the patch for GiST VACUUM.
> There are two main changes:
> 1. During rescan for page deletion only know to be recently empty pages are rescanned.
> 2. I've re-implemented physical scan with array instead of hash table.

There is one more minor spot in GiST VACUUM. It takes heap tuples count for statistics for partial indexes, while it should not.

If gistvacuumcleanup() is not given a statistics gathered by gistbulkdelete() it returns incorrect tuples count for partial index.
Here's the micropatch, which fixes that corner case.
To reproduce this effect I used this query:
create table y as select cube(random()) c from generate_series(1,10000) y; create index on y using gist(c) where c~>1 > 0.5;
vacuum verbose y;
Before patch it will report 10000 tuples, with patch it will report different values around 5000.

I do not know, should I register separate commitfest entry? The code is very close to main GiST VACUUM patch, but solves a bit different problem.

Best regards, Andrey Borodin.

Attachment Content-Type Size
0001-Count-tuples-correctly-during-GiST-VACUUM-of-partial.patch application/octet-stream 2.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2017-12-30 10:32:24 Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Previous Message Craig Ringer 2017-12-30 07:42:10 Re: [PATCH] session_replication_role = replica with TRUNCATE