Pg+dSpam: zvyseni vykonu

[Pavel Kankovsky]

On Wed, 14 Dec 2011, Tomas Vondra wrote:

> Ale to není až tak schizoidní - [...]

Schizoidností myslím to, že něco dělá jedním způsobem a něco jiným.
Updaty háže na hromadu a provádí v dávce, zatímco inserty provádí okamžitě
a individuálně. (Jasně, má to nějaké důvody, ale stejně to vypadá divně.)

> A ta vaše finta také fungovat nebude, protože ten INSERT vidí READ
> COMMITTED snapshot z okamžiku spuštění příkazu, takže pokud v době
> běhu nějaká další transakce commitne vhodný záznam tak to stejně
> spadne.

To máte pravdu.

Ale kdoví, zda by zkombinování insertů do jedné transakce přece jen nebylo
efektivnější než stávající stav, i kdyby to vyžadovalo nějaký zámek, který
by ty insertovací transakce serializoval.

Nebo by šlo udělat to, že primární klíč nebyl jen token ale token +
unikátní id transakce. Při čtení dat by se sečetly hodnoty ve všech
záznamech lišících se jen id transakce. Při ukládání změn by měnil
jen jeden záznam (např. by si při čtení zapamatoval nejmenší id),
při vytváření záznamů by tam dal nové id. Jednou za čas by něco provedlo
úklid a duplicitní záznamy sumarizovalo.

> To asi moc dobře fungovat nebude, protože pak stačí aby spadnul jeden
> INSERT z toho batche a spadne vám celý batch. Já osobně bych šel jinou
> cestou - nedělat to pro každý token, ale někde bokem si nasyslit a vždycky
> při dosažení stanovené hodnoty zkusit
> 
> SELECT token FROM tabulka WHERE token IN (token1, token2, ...)

Tohle tam už do jisté míry je, protože (jestli dobře chápu, jak to
funguje) on načte data z databáze, rychle něco spočítá, a pak hned ukládá
změny. A pamatuje si, které tokeny před chvílí v db našel a které
nikoli. A tudíž bych se až tolik nedivil, kdyby se vyplatilo udělat
nejdřív aspoň jeden pokus založený na této informaci.

-- 
Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /