|From:||"Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>|
|To:||Юрий Соколов <funny(dot)falcon(at)gmail(dot)com>|
|Cc:||Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>|
|Subject:||Re: [WIP] [B-Tree] Retail IndexTuple deletion|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 29.06.2018 14:07, Юрий Соколов wrote:
> чт, 28 июн. 2018 г., 8:37 Andrey V. Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru
> On 28.06.2018 05:00, Peter Geoghegan wrote:
> > On Tue, Jun 26, 2018 at 11:40 PM, Andrey V. Lepikhov
> > <a(dot)lepikhov(at)postgrespro(dot)ru <mailto:a(dot)lepikhov(at)postgrespro(dot)ru>> wrote:
> >> I still believe that the patch for physical TID ordering in btree:
> >> 1) has its own value, not only for target deletion,
> >> 2) will require only a few local changes in my code,
> >> and this patches can be developed independently.
> > I want to be clear on something now: I just don't think that this
> > patch has any chance of getting committed without something like my
> > own patch to go with it. The worst case for your patch without that
> > component is completely terrible. It's not really important for
> you to
> > actually formally make it part of your patch, so I'm not going to
> > insist on that or anything, but the reality is that my patch does not
> > have independent value -- and neither does yours.
> As I wrote before in the last email, I will integrate TID sorting to my
> patches right now. Please, give me access to the last version of your
> code, if it possible.
> You can track the progress at https://github.com/danolivo/postgres git
> Peter is absolutely right, imho: tie-breaking by TID within index
> ordering is inevitable for reliable performance of this patch.
In the new version the patch  was used in cooperation with 'retail
indextuple deletion' and 'quick vacuum strategy' patches (see
To demonstrate the potential benefits, I did a test:
CREATE TABLE test (id serial primary key, value integer, factor integer);
INSERT INTO test (value, factor) SELECT random()*1e5, random()*1e3 FROM
CREATE INDEX ON test(value);
DELETE FROM test WHERE (factor = 1);
Execution time of last "VACUUM test;" command on my notebook was:
with bulk deletion: 1.6 s;
with Quick Vacuum Strategy: 5.2 s;
with Quick Vacuum Strategy & TID sorting: 0.6 s.
> With regards,
> Sokolov Yura.
The Russian Postgres Company
|Next Message||Andrew Dunstan||2018-07-02 14:30:11||Old small commitfest items|
|Previous Message||Tom Lane||2018-07-02 14:16:22||Re: Should contrib modules install .h files?|