Dva relativně jednoduché patche související s BRIN indexy

[Tomas Vondra]

Ahoj,

pokud by si někdo chtěl zkusit napsat a dostat patch do PostgreSQL, měl
bych tipy na dvě vylepšení BRIN indexů:


1) ignorování BRIN indexů při vyhodnocování zda jde použít HOT

Aktuálně BRIN indexy blokují HOT, stejně jako např. btree indexy apod.
To ale není nutné, protože neobsahují odkazy na jednotlivé řádky.
Vyřešit to je otázka přidání nějakého flagu do AM descriptoru, a jeho
kontrola v HOT kódu.


2) flexibilní řešení situace kdy BRIN řádek přeroste stránku

Aktuálně pokud BRIN řádek (který nějak popisuje hodnoty z mnoha řádek
tabulky) přeroste 8kB, tak operace (INSERT/UPDATE) prostě selže, což je
nepříjemné. Ideální by bylo to vyřešit např. tak že se smaže a celý ten
interval se bude brát jako odpovídající všem dotazům. Tohle je trochu
větší / komplikovanější patch, ale nic extra složitého - pořád je to
celkem dobře izolované v jednom modulu.


Pochopitelně, s oběma projekty bych vám nějak asistoval apod.

Pišu to i proto že aktuálně běží přihlášky do letošního Google Summer of
Code, a ten druhý patch by asi mohl být celkem dobrý projekt. Není to
ani moc malé ani moc komplikované, a přijde mi to i jako celkem vhodné
téma pro někoho kdo zatím pro Postgres nic nenapsal.

Čili pokud by tu byl nějaký student který by to chtěl zkusit, dejte mi
vědět. Ale je potřeba to řešit hned, ty přihlášky jsou jenom do 13.4.


T.

[Josef Šimánek]

út 6. 4. 2021 v 21:52 odesílatel Tomas Vondra <t...@fuzzy.cz> napsal:
>
> Ahoj,

ahoj

Pokud se do 13.4. nepřihlásí nějáký student, já se na to klidně zase podívám.

>
> T.
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/916cdcb2-9635-fa12-7441-02d851bf3ab2%40fuzzy.cz.

[Josef Šimánek]

út 6. 4. 2021 v 22:00 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

Jelikož mi Tomáš nedávno připomenul, že se toho nikdo neujal, tak jsem
na to koukl.

Zatím jsem pokročil s ignorováním BRIN indexů při vyhodnocování zda
jde použít HOT. Kód a trochu informací je k dispozici na
https://github.com/simi/postgres/pull/7. Budu rád za každou
připomínku, než se to odvážím poslat do hackers.

[Pavel Stehule]

ne 13. 6. 2021 v 20:37 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

tenhle fragment vypada dobre. Tam bude spis komplikovanejsi jak napsat test a jak potvrdit Tomasovo tvrzeni, ze BRIN index nemusi blokovat HOT.

Pavel

 

>
> >
> > T.
> >
> > --
> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
> > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> > Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/916cdcb2-9635-fa12-7441-02d851bf3ab2%40fuzzy.cz.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFp7Qwoyz1XTUfkdntRkHo6UDXHfxdSmPBJL7hW7LjJMztKfRw%40mail.gmail.com.

[Josef Šimánek]

ne 13. 6. 2021 v 20:54 odesílatel Pavel Stehule
<pavel....@gmail.com> napsal:

No test je v podstatě napsanej tom pull requestu. Přesunout to regress
testů by neměl bejt zas takovej problém. Jen mi tam vadí ten pg_sleep.

Není možnost vynutit přepočítání pg_stat_user_tables, takže by se
nemuselo čekat, než se to stane samo?

> Pavel
>
>>
>>
>> >
>> > >
>> > > T.
>> > >
>> > > --
>> > > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
>> > > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
>> > > Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/916cdcb2-9635-fa12-7441-02d851bf3ab2%40fuzzy.cz.
>>
>> --
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
>> Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFp7Qwoyz1XTUfkdntRkHo6UDXHfxdSmPBJL7hW7LjJMztKfRw%40mail.gmail.com.
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

> Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB-1zpOZ_PvyHZrqe0UdG4y_kd2aMsn6zsUT8okYBp1XA%40mail.gmail.com.

[Pavel Stehule]

ne 13. 6. 2021 v 21:27 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

nejake moznosti tam jsou

https://stackoverflow.com/questions/41421429/pg-stat-activity-doesnt-update-within-a-procedure-or-transaction

> Pavel
>
>>
>>
>> >
>> > >
>> > > T.
>> > >
>> > > --
>> > > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
>> > > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
>> > > Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/916cdcb2-9635-fa12-7441-02d851bf3ab2%40fuzzy.cz.
>>
>> --
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
>> Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFp7Qwoyz1XTUfkdntRkHo6UDXHfxdSmPBJL7hW7LjJMztKfRw%40mail.gmail.com.
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFj8pRB-1zpOZ_PvyHZrqe0UdG4y_kd2aMsn6zsUT8okYBp1XA%40mail.gmail.com.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/CAFp7Qwq9AAmmrr8_mBC0eC2y7B1jmTLEoqXpJ7g5bC7p2yxHrA%40mail.gmail.com.

[Tomas Vondra]

On 6/13/21 8:54 PM, Pavel Stehule wrote:
>
>
> ne 13. 6. 2021 v 20:37 odesílatel Josef Šimánek <josef....@gmail.com

> <mailto:josef....@gmail.com>> napsal:

>
> út 6. 4. 2021 v 22:00 odesílatel Josef Šimánek

> <josef....@gmail.com <mailto:josef....@gmail.com>> napsal:

> >
> > út 6. 4. 2021 v 21:52 odesílatel Tomas Vondra <t...@fuzzy.cz

> <mailto:t...@fuzzy.cz>> napsal:

> <https://github.com/simi/postgres/pull/7>. Budu rád za každou

> připomínku, než se to odvážím poslat do hackers.
>
>
> tenhle fragment vypada dobre. Tam bude spis komplikovanejsi jak napsat
> test a jak potvrdit Tomasovo tvrzeni, ze BRIN index nemusi blokovat HOT.
>

Ano, ten fragment vypadá rozumně (ale netestoval jsem to).

Nerozumím proč by měl být problém obhájit tvrzení že BRIN indexy jsou
pro HOT irelevantní - pro HOT jsou problém indexy které mohou obsahovat
odkaz na TID toho updatovaného řádku, ale BRIN vůbec žádné pointery na
jednotlivé řádky neobsahují.

T.

[Pavel Stehule]

ne 13. 6. 2021 v 22:35 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:

BRIN index adresuje jenom stranku?

Pavel

T.

[David Turoň]

Ahoj,

me by prislo u BRIN zajimave mit moznost ho vyuzit pri agregaci min/max ... kdyz clovek nahradi BTREE za BRIN tak pak prijde o moznost SELECT max(id) FROM t; s pouzitim indexu. Takhle by stacilo misto seq scanu projit ty interni struktury indexu a tam jsou minima a maxima pro jednotlivy rozsah stranek jesti se nepletu.

lbstat=# CREATE TABLE t AS SELECT * FROM generate_series(1,1000000) AS k(x);
SELECT 1000000
lbstat=# CREATE INDEX ON t (x);
CREATE INDEX

lbstat=# EXPLAIN SELECT max(x) FROM t;
                                              QUERY PLAN                                              
------------------------------------------------------------------------------------------------------
 Result  (cost=0.47..0.48 rows=1 width=4)
   InitPlan 1 (returns $0)
     ->  Limit  (cost=0.42..0.47 rows=1 width=4)
           ->  Index Only Scan Backward using t_x_idx on t  (cost=0.42..46040.93 rows=995000 width=4)
                 Index Cond: (x IS NOT NULL)
(5 řádek)

lbstat=# DROP INDEX t_x_idx ;
DROP INDEX
lbstat=# CREATE INDEX ON t USING BRIN(x);
CREATE INDEX

lbstat=# EXPLAIN SELECT max(x) FROM t;
                                     QUERY PLAN                                    
------------------------------------------------------------------------------------
 Finalize Aggregate  (cost=10633.55..10633.56 rows=1 width=4)
   ->  Gather  (cost=10633.33..10633.54 rows=2 width=4)
         Workers Planned: 2
         ->  Partial Aggregate  (cost=9633.33..9633.34 rows=1 width=4)
               ->  Parallel Seq Scan on t  (cost=0.00..8591.67 rows=416667 width=4)
(5 řádek)

David

út 6. 4. 2021 v 21:52 odesílatel Tomas Vondra <t...@fuzzy.cz> napsal:

[Pavel Stehule]

po 14. 6. 2021 v 6:28 odesílatel Pavel Stehule <pavel....@gmail.com> napsal:

a odpovim si sam, - adresuje

Pavel

Pavel

T.

[Tomas Vondra]

On 6/14/21 11:53 AM, David Turoň wrote:
> Ahoj,
>
> me by prislo u BRIN zajimave mit moznost ho vyuzit pri agregaci min/max
> ... kdyz clovek nahradi BTREE za BRIN tak pak prijde o moznost SELECT
> max(id) FROM t; s pouzitim indexu. Takhle by stacilo misto seq scanu
> projit ty interni struktury indexu a tam jsou minima a maxima pro
> jednotlivy rozsah stranek jesti se nepletu.
>

Jasně, to by bylo zajímavé, a možná by to ani nebylo úplně komplikované
naimplementovat. Takhle z hlavy mne napadají dvě věci které by bylo
potřeba vyřešit:

1) Ne každý BRIN index ukládá min/max - některé varianty ukládají např.
polygony (pro GIS data), nebo bloom filtry. Ale to by se dalo vyřešit
nějakým "flagem" v deskriptoru indexu.

2) Nestačí se dívat jenom na ty min/max, protože to nemusí být úplně
aktuální (např. po smazání řádku tam může být už neplatné min/max). Ale
pokud se by bloky seřadí podle (min), projdou se jednotlivé řádky a pak
se to zastaví když všechny další bloky mají "min" větší než to nalezené,
tak by to mělo fungovat.

Do velké míry by asi šlo okopírovat kód z btree indexů, přinejmenším ta
část z plánovače (což je často to nejsložitější).

T.

[Pavel Stehule]

po 14. 6. 2021 v 15:00 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:

On 6/14/21 11:53 AM, David Turoň wrote:
> Ahoj,
>
> me by prislo u BRIN zajimave mit moznost ho vyuzit pri agregaci min/max
> ... kdyz clovek nahradi BTREE za BRIN tak pak prijde o moznost SELECT
> max(id) FROM t; s pouzitim indexu. Takhle by stacilo misto seq scanu
> projit ty interni struktury indexu a tam jsou minima a maxima pro
> jednotlivy rozsah stranek jesti se nepletu.
>

Jasně, to by bylo zajímavé, a možná by to ani nebylo úplně komplikované
naimplementovat. Takhle z hlavy mne napadají dvě věci které by bylo
potřeba vyřešit:

v podstate by to mohlo fungovat tak trochu jako sloupcovy engine :)

Pokud si vzpominam, tak ve strankach ve vertice se ukladalo taky min, max - a dala by se tam ulozit suma a pocet

Pavel

1) Ne každý BRIN index ukládá min/max - některé varianty ukládají např.
polygony (pro GIS data), nebo bloom filtry. Ale to by se dalo vyřešit
nějakým "flagem" v deskriptoru indexu.

2) Nestačí se dívat jenom na ty min/max, protože to nemusí být úplně
aktuální (např. po smazání řádku tam může být už neplatné min/max). Ale
pokud se by bloky seřadí podle (min), projdou se jednotlivé řádky a pak
se to zastaví když všechny další bloky mají "min" větší než to nalezené,
tak by to mělo fungovat.

Do velké míry by asi šlo okopírovat kód z btree indexů, přinejmenším ta
část z plánovače (což je často to nejsložitější).

T.

--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny PostgreSQL-cz ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/postgresql-cz/872186e5-08ab-7da5-66db-07e2b9ea9b32%40gmail.com.

[Tomas Vondra]

On 6/14/21 3:42 PM, Pavel Stehule wrote:

po 14. 6. 2021 v 15:00 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:

On 6/14/21 11:53 AM, David Turoň wrote:
> Ahoj,
>
> me by prislo u BRIN zajimave mit moznost ho vyuzit pri agregaci min/max
> ... kdyz clovek nahradi BTREE za BRIN tak pak prijde o moznost SELECT
> max(id) FROM t; s pouzitim indexu. Takhle by stacilo misto seq scanu
> projit ty interni struktury indexu a tam jsou minima a maxima pro
> jednotlivy rozsah stranek jesti se nepletu.
>

Jasně, to by bylo zajímavé, a možná by to ani nebylo úplně komplikované
naimplementovat. Takhle z hlavy mne napadají dvě věci které by bylo
potřeba vyřešit:

v podstate by to mohlo fungovat tak trochu jako sloupcovy engine :)

Pokud si vzpominam, tak ve strankach ve vertice se ukladalo taky min, max - a dala by se tam ulozit suma a pocet

Ale Vertica nemá tradiční indexy, a to min/max a další info je aktualizované apod.

To BRIN indexy nemají - když smažeš řádek ze stránky tak min/max se nepřepočítají. A to samé suma.

T.

[Pavel Stehule]

út 15. 6. 2021 v 11:10 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:

ale to by slo udelat. Stejne jako ted kontrolujes jestli min/max souhlasi

Pavel

T.

[Tomas Vondra]

Teď se přes min/max vyfiltruje úsek tabulky jako obsahující "potenciálně zajímavé" stránky, a pak se to projde řádek to řádku a znovu se vyhodnotí ty podmínky. To u předpočítané sumy úplně ztrácí smysl.

T.

[Tomas Vondra]

On 6/13/21 9:27 PM, Josef Šimánek wrote:
> ne 13. 6. 2021 v 20:54 odesílatel Pavel Stehule
> <pavel....@gmail.com> napsal:
>> ne 13. 6. 2021 v 20:37 odesílatel Josef Šimánek <josef....@gmail.com> napsal:
>>> út 6. 4. 2021 v 22:00 odesílatel Josef Šimánek <josef....@gmail.com> napsal:

>>> ...

>>> Jelikož mi Tomáš nedávno připomenul, že se toho nikdo neujal, tak jsem
>>> na to koukl.
>>>
>>> Zatím jsem pokročil s ignorováním BRIN indexů při vyhodnocování zda
>>> jde použít HOT. Kód a trochu informací je k dispozici na
>>> https://github.com/simi/postgres/pull/7. Budu rád za každou
>>> připomínku, než se to odvážím poslat do hackers.
>>
>> tenhle fragment vypada dobre. Tam bude spis komplikovanejsi jak napsat test a jak potvrdit Tomasovo tvrzeni, ze BRIN index nemusi blokovat HOT.
> No test je v podstatě napsanej tom pull requestu. Přesunout to regress
> testů by neměl bejt zas takovej problém. Jen mi tam vadí ten pg_sleep.
>
> Není možnost vynutit přepočítání pg_stat_user_tables, takže by se
> nemuselo čekat, než se to stane samo?

První commitfest pro PG15 začíná ve čtvrtek, tak by bylo dobré ten patch
poslat do konference a přidat do CF aplikace [1], jinak se to zbytečně
posune až do dalšího CF. Klidně bych tam poslal ten existující diff, s
tím že zbytek se pořeší v rámci reviews.

Co se týká toho testu, to jak čekat na statistiky jde obšlehnout z
existujících testů - viz. funkce wait_for_stats v stats.sql. Bez
pg_sleep se to neobejde, ale je třeba to dělat ve smyčce (kvůli pomalým
strojům a buildům s valgrindem apod. na kterých to může trvat možná i
desítky vteřin).

[1] https://commitfest.postgresql.org/33/

T.

[Josef Šimánek]

po 28. 6. 2021 v 23:01 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:

Super, dík za radu. Zítra to dám dohromady a pošlu do commitfestu.

> [1] https://commitfest.postgresql.org/33/
>
> T.

[Josef Šimánek]

po 28. 6. 2021 v 23:04 odesílatel Josef Šimánek

Tak je to tam.

https://commitfest.postgresql.org/33/3218/

> > [1] https://commitfest.postgresql.org/33/
> >
> > T.

[Josef Šimánek]

Sice to chvilku trvalo, ale nakonec se to tam Tomášovi podařilo protlačit.

Viz https://www.postgresql.org/message-id/c9a45a90-ed8c-61c6-c04e-e23d5dbbe415%40enterprisedb.com a https://github.com/postgres/postgres/commit/5753d4ee320b3f6fb2ff734667a1ce1d9d8615a1.

Tomáši, pokud je stále i ten druhý nápad z původní zprávy relevantní, rád se do něho zase ponořím. Pokud by zas bylo menší info pro nakopnutí k dispozici, budu jen rád.

Dne středa 30. června 2021 v 0:33:50 UTC+2 uživatel Josef Šimánek napsal:

[Tomas Vondra]

On 12/1/21 02:20, Josef Šimánek wrote:
> Sice to chvilku trvalo, ale nakonec se to tam Tomášovi podařilo protlačit.
>
> Viz https://www.postgresql.org/message-id/c9a45a90-ed8c-61c6-c04e-e23d5dbbe415%40enterprisedb.com
> a
> https://github.com/postgres/postgres/commit/5753d4ee320b3f6fb2ff734667a1ce1d9d8615a1.
>
> Tomáši, pokud je stále i ten druhý nápad z původní zprávy relevantní,
> rád se do něho zase ponořím. Pokud by zas bylo menší info pro nakopnutí
> k dispozici, budu jen rád.
>

No, v zásadě jde o to že indexy nepodporují TOAST, takže pokud BRIN
vygeneruje příliš velký souhrn pro daný rozsah řádek, tak to zablokuje
inserty/updaty. Příklad:

test=# create table t (a bytea);
CREATE TABLE
test=# create index on t using brin (a);
CREATE INDEX
test=# insert into t
select ('\x' || string_agg(md5(random()::text),''))::bytea
from generate_series(1,400) s(i);
ERROR: index row size 12816 exceeds maximum 8152 for index "t_a_idx"


test=# drop index t_a_idx;
DROP INDEX
test=# insert into t
select ('\x' || string_agg(md5(random()::text),''))::bytea
from generate_series(1,400) s(i);
INSERT 0 1
test=# create index on t using brin (a);
ERROR: index row size 12816 exceeds maximum 8152 for index "t_a_idx"

Ostatní indexy mají obdobný problém, ale pro BRIN je to trochu horší
protože se ukládá hodnota spočtená z více řádek, což může růst rychleji,
a současně je to nepredikovatelné podle toho jak se řádky sejdou apod. U
btree indexů je to predikovatelnější - tam se to chová konzistentně.

Řešení je v principu asi jednoduché - prostě udělat "retry" a to summary
"vymazat", tj. nastavit na NULL tvářit se že odpovídá všem dotazům. To
znamená že brin_doinsert/brin_doupdate tohle musí detekovat (a vrátit
false místo házení erroru, nebo tak něco), a volající na to musí nějak
reagovat - přegenerovat summary, vložit znovu.

To je asi tak všechno co pro začátek mám - víc se zjistí až při psaní
patche. Určitě tam bude potřeba trochu kreativity při řešení, např.
pokud je to multicolumn index tak nemusí být nutno resetovat info pro
všechny sloupce, ale jenom minimum než se dostaneme pod BrinMaxItemSize)
a některé opclass mohou umožňovat jiná řešení (např. u minmax-multi se
dá redukovat počet hodnot). Ale to bych zatím ignoroval, stačí když to
bude umět ten reset.


BTW když jsem před časem mluvil s Alvarem (kterej BRIN indexy napsal)
tak jsme si říkali že by bylo hezký umět BRIN indexy používat pro
routování řádek, tj. umět nějak preferovat pozici v tabulce kde už
odpovídá aktuálnímu BRIN indexu (a ne jenom podle volného místa). To už
je zase o něco složitější, ale možná zajímavá myšlenka na další patch.

T.

[Tomas Vondra]

On 12/1/21 05:03, Tomas Vondra wrote:
> On 12/1/21 02:20, Josef Šimánek wrote:
>> Sice to chvilku trvalo, ale nakonec se to tam Tomášovi podařilo
>> protlačit.
>>
>> Viz https://www.postgresql.org/message-id/c9a45a90-ed8c-61c6-c04e-e23d5dbbe415%40enterprisedb.com
>> a
>> https://github.com/postgres/postgres/commit/5753d4ee320b3f6fb2ff734667a1ce1d9d8615a1.
>>
>>
>> Tomáši, pokud je stále i ten druhý nápad z původní zprávy relevantní,
>> rád se do něho zase ponořím. Pokud by zas bylo menší info pro
>> nakopnutí k dispozici, budu jen rád.
>>

Jinak tedy v tom e-mailu do hackers jsem spekuloval o možnosti aplikovat
HOT i pokud se updatují sloupce jen v partial indexech u kterých není
splněna WHERE podmínka (čili ten řádek se reálně neodkazuje). Což by
myslím jít mělo, večer jsem na to napsal víceméně funkční (dost hnusnej)
PoC patch. Pokud by se toho někdo chtěl ujmout a zkusit to doladit atd.
rád s tím pomůžu.

T.

[Josef Šimánek]

st 1. 12. 2021 v 20:09 odesílatel Tomas Vondra <tv.f...@gmail.com> napsal:

Jako vždy jsem tu pro každou lumpárnu. Sem s tím.

> T.

[Tomas Vondra]

Tady je ten PoC patch - určitě to bude potřeboat refactoring (teď je to
narychlo nahackované v jednom místě), různé optimalizace a úpravy
zmíněné v komentářích (aby se furt neotevíraly indexy apod.). A pak
samozřejmě testy že se to chová správně a měření zda to reálně pomáhá.

T.