Zpomalení o 3 řády po přechodu na PG 9.2

[Jiri Skopik/8BC Ltd.]

Zdravím, prosím o nějakou radu k problému, co se mi vyskytl.

 

Mám funkci, která dělá zhruba toto:

-          na vstupu je XML soubor

-          funkce se podívá, jaký časový úsek v XML je, tento smaže z databáze a nahradí ho novým, který získá zpracováním vstupu (mění se obsah jediné tabulky)

-          na závěr udělá select, který vrátí, co je v právě vložených datech „navíc“ (hned při vkládání se to poznat nedá, je potřeba se pak na to podívat jako na celek) a tyto řádky se smažou (oproti všem vloženým datům je jich malý zlomek)

 

Ve verzi 9.1 to fungovalo dobře, při upgrade na 9.2 (konkrétně jsem zkoušel 9.2.2 a 9.2.3 – je to stejné) je ale funkce výrazně pomalejší.

Po prozkoumání jsem zjistil, že za to může ten poslední krok, který hledá ty přebytečné řádky. „Rychlá“ varianta trvá okolo 100ms, „pomalá“ asi 90s. Nejprve jsem podezříval mazání (je tam trigr), ale není to tak, pomalé je to zjištění, co se má smazat (ten select není úplně triviální, používá funkci, která je napsaná rekurzivně - nemůže to být stopa?).

Zvláštní je, že takhle pomalé je to jenom v té funkci – když tuhle část z funkce odstraním a po jejím doběhnutí zavolám zvlášť, je to rychlé.

Další zajímavá věc na kterou jsem přišel je ta, že když si tuto část dám do jiné funkce a tu volám 2×, jednou před zpracováním dat a podruhé po, projdou rychle obě. Pokud ji ale volám jenom po, je to pomalé.

Mám prováděcí plány, ale moc je neumím číst. Dokáže z toho prosím někdo zjistit, kde je problém a hlavně co změnit, aby to zase chodilo rychle?

Díky předem.

 

Rychlá verze:

Sort  (cost=1951.82..1951.87 rows=18 width=8)

  Sort Key: i."Index"

  CTE pl

    ->  HashAggregate  (cost=172.20..172.44 rows=24 width=8)

          ->  Seq Scan on pl_sync  (cost=0.00..172.14 rows=24 width=8)

                Filter: (date IS NOT NULL)

  ->  HashAggregate  (cost=1778.78..1779.00 rows=18 width=8)

        ->  Hash Join  (cost=189.03..1777.18 rows=320 width=8)

              Hash Cond: (i."Date" = pl.date)

              ->  Hash Join  (cost=188.25..1763.99 rows=2457 width=16)

                    Hash Cond: (i."SSectionID" = s."ID")

                    ->  Seq Scan on "PL_items" i  (cost=186.36..1637.72 rows=26615 width=20)

                          Filter: (NOT (hashed SubPlan 2))

                          SubPlan 2

                            ->  CTE Scan on pl  (cost=0.00..126.36 rows=24000 width=8)

                    ->  Hash  (cost=1.81..1.81 rows=6 width=4)

                          ->  Seq Scan on "PL_station_sections" s  (cost=0.00..1.81 rows=6 width=4)

                                Filter: ("StationID" = 3)

              ->  Hash  (cost=0.48..0.48 rows=24 width=8)

                    ->  CTE Scan on pl  (cost=0.00..0.48 rows=24 width=8)

 

Pomalá verze:

Sort  (cost=5522830.04..5522830.08 rows=18 width=8)

  Sort Key: i."Index"

  CTE pl

    ->  HashAggregate  (cost=291.68..293.68 rows=200 width=8)

          ->  Seq Scan on pl_sync  (cost=0.00..265.65 rows=10413 width=8)

                Filter: (date IS NOT NULL)

  ->  HashAggregate  (cost=5522535.76..5522535.98 rows=18 width=8)

        ->  Nested Loop  (cost=0.00..5522523.47 rows=2457 width=8)

              Join Filter: (i."Date" = pl.date)

              ->  CTE Scan on pl  (cost=0.00..4.00 rows=200 width=8)

              ->  Materialize  (cost=0.00..5515154.61 rows=2457 width=16)

                    ->  Nested Loop  (cost=0.00..5515142.33 rows=2457 width=16)

                          ->  Seq Scan on "PL_station_sections" s  (cost=0.00..1.81 rows=6 width=4)

                                Filter: ("StationID" = 3)

                          ->  Index Scan using "PL_items_idx" on "PL_items" i  (cost=0.00..919184.18 rows=591 width=20)

                                Index Cond: ("SSectionID" = s."ID")

                                Filter: (NOT (SubPlan 2))

                                SubPlan 2

                                  ->  CTE Scan on pl  (cost=0.00..1053.00 rows=200000 width=8)

[Tomas Vondra]

Dne 08.02.2013 12:04, Jiri Skopik/8BC Ltd. napsal:
> *

>
> Mám prováděcí plány, ale moc je neumím číst. Dokáže z toho
> prosím někdo zjistit, kde je problém a hlavně co změnit, aby to
> zase chodilo rychle?

A můžeme dostat také ten SQL dotaz + informace o tabulkách (struktura,
počet řádek, velikost v MB)?

Neuškodila by také informace o základních nastaveních PostgreSQL, které
mohou ovlivnit plánování (shared_buffers, work_mem apod.)

T.

[Pavel Stehule]

Ahoj

v 9.2 se dynamicky optimalizuji provadeci plany v PL/pgSQL - coz
pomaha, pokud sedi statistiky a naopak muze zhorsit, pokud statistiky
nesedi.

Takze minimalne potrebujeme EXPLAIN ANALYZE, pripadne EXPLAIN ANALYZE VERBOSE

+ konfiguraci - work_mem, random_page_cost, seq_page_cost

z nejakeho duvodu si to mysli, ze nested loop s index scanem je
levnejsi nez hash_join

Pavel

Dne 8. února 2013 12:04 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.
> Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-maily,
> zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> Další možnosti najdete na adrese https://groups.google.com/groups/opt_out.
>
>

[Jiri Skopik/8BC Ltd.]

> -----Original Message-----
> From: postgr...@googlegroups.com [mailto:postgresql-
> c...@googlegroups.com] On Behalf Of Pavel Stehule
> Sent: Friday, February 08, 2013 12:18 PM
> To: postgr...@googlegroups.com
> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>
> Ahoj
>
> v 9.2 se dynamicky optimalizuji provadeci plany v PL/pgSQL - coz
> pomaha, pokud sedi statistiky a naopak muze zhorsit, pokud statistiky
> nesedi.
>
> Takze minimalne potrebujeme EXPLAIN ANALYZE, pripadne EXPLAIN ANALYZE
> VERBOSE
>
> + konfiguraci - work_mem, random_page_cost, seq_page_cost
>

Konfigurace by měla být defaultní (je to na Windows7):
work_mem=1024
random_page_cost=4
seq_page_cost=1
shared_buffers=4096


Tabulka, se kterou se pracuje, má asi 11MB, což je 53205 řádků (při datech, na kterých to testuju, se jich 126 smaže, 150 vloží a ten poslední krok jich 24 vyhodí).


Ten select vypadá takhle (sid a fid jsou parametry):
WITH pl AS (SELECT DISTINCT date FROM pl_sync WHERE date notnull)
SELECT i."ID" FROM "PL_items" i JOIN "PL_station_sections" s ON s."StationID"=sid AND s."ID"=i."SSectionID" JOIN pl ON i."Date"=pl.date
WHERE i."ID" NOT IN (SELECT ("PlaylistSection"(fid,date,date))."ID" FROM pl) ORDER BY "Index" DESC;


EXPLAIN ANALYZE VERBOSE rychlý/pomalý:

Sort (cost=1962.94..1963.74 rows=320 width=8) (actual time=122.965..122.966 rows=24 loops=1)
Output: i."ID", i."Index"
Sort Key: i."Index"
Sort Method: quicksort Memory: 17kB
CTE pl
-> HashAggregate (cost=172.20..172.44 rows=24 width=8) (actual time=1.858..1.862 rows=24 loops=1)
Output: pl_sync.date
-> Seq Scan on public.pl_sync (cost=0.00..172.14 rows=24 width=8) (actual time=0.022..1.838 rows=24 loops=1)
Output: pl_sync.date
Filter: (pl_sync.date IS NOT NULL)
Rows Removed by Filter: 1090
-> Hash Join (cost=189.03..1777.18 rows=320 width=8) (actual time=106.494..122.954 rows=24 loops=1)
Output: i."ID", i."Index"

Hash Cond: (i."Date" = pl.date)

-> Hash Join (cost=188.25..1763.99 rows=2457 width=16) (actual time=99.153..120.975 rows=780 loops=1)
Output: i."ID", i."Index", i."Date"

Hash Cond: (i."SSectionID" = s."ID")

-> Seq Scan on public."PL_items" i (cost=186.36..1637.72 rows=26615 width=20) (actual time=91.446..114.299 rows=53103 loops=1)
Output: i."ID", i."SSectionID", i."Date", i."Index", i."Time", i."TypeID", i."ElementID", i."Status", i."Startpos", i."Chain", i."Skip", i."Imported", i."Lock", i."Expanded", i."Runtime", i."Mixtime", i."Played", i."Volume", i."MixID", i."MixUser", i."UserCueIn", i."UserCueOut", i."UserFadeIn", i."UserFadeOut", i."Script", i."Airtime"

Filter: (NOT (hashed SubPlan 2))

Rows Removed by Filter: 126
SubPlan 2
-> CTE Scan on pl (cost=0.00..126.36 rows=24000 width=8) (actual time=15.025..91.342 rows=126 loops=1)
Output: ("PlaylistSection"(10, pl.date, pl.date))."ID"
-> Hash (cost=1.81..1.81 rows=6 width=4) (actual time=0.014..0.014 rows=6 loops=1)
Output: s."ID"
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> Seq Scan on public."PL_station_sections" s (cost=0.00..1.81 rows=6 width=4) (actual time=0.005..0.013 rows=6 loops=1)
Output: s."ID"
Filter: (s."StationID" = 3)
Rows Removed by Filter: 59
-> Hash (cost=0.48..0.48 rows=24 width=8) (actual time=1.875..1.875 rows=24 loops=1)
Output: pl.date
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> CTE Scan on pl (cost=0.00..0.48 rows=24 width=8) (actual time=1.859..1.869 rows=24 loops=1)
Output: pl.date
Total runtime: 123.180 ms


Sort (cost=5522955.52..5522961.66 rows=2457 width=8) (actual time=84860.423..84860.423 rows=24 loops=1)
Output: i."ID", i."Index"
Sort Key: i."Index"
Sort Method: quicksort Memory: 17kB
CTE pl
-> HashAggregate (cost=291.68..293.68 rows=200 width=8) (actual time=0.226..0.245 rows=24 loops=1)
Output: pl_sync.date
-> Seq Scan on pg_temp_6.pl_sync (cost=0.00..265.65 rows=10413 width=8) (actual time=0.003..0.217 rows=24 loops=1)
Output: pl_sync.date
Filter: (pl_sync.date IS NOT NULL)
Rows Removed by Filter: 1090
-> Nested Loop (cost=0.00..5522523.47 rows=2457 width=8) (actual time=36866.245..84860.415 rows=24 loops=1)
Output: i."ID", i."Index"

Join Filter: (i."Date" = pl.date)

Rows Removed by Join Filter: 18696
-> CTE Scan on pl (cost=0.00..4.00 rows=200 width=8) (actual time=0.227..0.231 rows=24 loops=1)
Output: pl.date
-> Materialize (cost=0.00..5515154.61 rows=2457 width=16) (actual time=4.826..3535.729 rows=780 loops=24)
Output: i."ID", i."Index", i."Date"
-> Nested Loop (cost=0.00..5515142.33 rows=2457 width=16) (actual time=115.831..84855.665 rows=780 loops=1)
Output: i."ID", i."Index", i."Date"
-> Seq Scan on public."PL_station_sections" s (cost=0.00..1.81 rows=6 width=4) (actual time=0.004..0.016 rows=6 loops=1)
Output: s."ID", s."StationID", s."SectionID", s."InterfaceID", s."Style"
Filter: (s."StationID" = 3)
Rows Removed by Filter: 59
-> Index Scan using "PL_items_idx" on public."PL_items" i (cost=0.00..919184.18 rows=591 width=20) (actual time=69.053..14142.514 rows=130 loops=6)
Output: i."ID", i."SSectionID", i."Date", i."Index", i."Time", i."TypeID", i."ElementID", i."Status", i."Startpos", i."Chain", i."Skip", i."Imported", i."Lock", i."Expanded", i."Runtime", i."Mixtime", i."Played", i."Volume", i."MixID", i."MixUser", i."UserCueIn", i."UserCueOut", i."UserFadeIn", i."UserFadeOut", i."Script", i."Airtime"
Index Cond: (i."SSectionID" = s."ID")
Filter: (NOT (SubPlan 2))
Rows Removed by Filter: 21
SubPlan 2
-> CTE Scan on pl (cost=0.00..1053.00 rows=200000 width=8) (actual time=5.142..93.633 rows=117 loops=906)
Output: ("PlaylistSection"(10, pl.date, pl.date))."ID"
Total runtime: 84860.496 ms

> z nejakeho duvodu si to mysli, ze nested loop s index scanem je
> levnejsi nez hash_join
>
> Pavel
>
> Dne 8. února 2013 12:04 Jiri Skopik/8BC Ltd. <sko...@8bc.com>
> napsal(a):
> > Zdravím, prosím o nějakou radu k problému, co se mi vyskytl.
> >
> >
> >
> > Mám funkci, která dělá zhruba toto:
> >
> > - na vstupu je XML soubor
> >
> > - funkce se podívá, jaký časový úsek v XML je, tento smaže z
> > databáze a nahradí ho novým, který získá zpracováním vstupu (mění se
> obsah
> > jediné tabulky)
> >
> > - na závěr udělá select, který vrátí, co je v právě
> vložených
> > datech "navíc" (hned při vkládání se to poznat nedá, je potřeba se
> pak na to
> > podívat jako na celek) a tyto řádky se smažou (oproti všem vloženým
> datům je
> > jich malý zlomek)
> >
> >
> >
> > Ve verzi 9.1 to fungovalo dobře, při upgrade na 9.2 (konkrétně jsem
> zkoušel

> > 9.2.2 a 9.2.3 - je to stejné) je ale funkce výrazně pomalejší.

> >
> > Po prozkoumání jsem zjistil, že za to může ten poslední krok, který
> hledá ty
> > přebytečné řádky. "Rychlá" varianta trvá okolo 100ms, "pomalá" asi
> 90s.
> > Nejprve jsem podezříval mazání (je tam trigr), ale není to tak,
> pomalé je to
> > zjištění, co se má smazat (ten select není úplně triviální, používá
> funkci,
> > která je napsaná rekurzivně - nemůže to být stopa?).
> >

> > Zvláštní je, že takhle pomalé je to jenom v té funkci - když tuhle

[Pavel Stehule]

Dne 8. února 2013 13:54 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

> SubPlan 2
> -> CTE Scan on pl (cost=0.00..1053.00 rows=200000 width=8) (actual time=5.142..93.633 rows=117 loops=906)
> Output: ("PlaylistSection"(10, pl.date, pl.date))."ID"

Prijde mi hrozne divne, jak se pg dostane k 200 000 radkum u toho CTE

SubPlan 2
-> CTE Scan on pl (cost=0.00..1053.00
rows=200000 width=8) (actual time=5.142..93.633 rows=117 loops=906)
Output: ("PlaylistSection"(10,
pl.date, pl.date))."ID"

Nemate tam nastaveny ROWS u funkce PlaylistSection ??

[Jiri Skopik/8BC Ltd.]

> -----Original Message-----
> From: postgr...@googlegroups.com [mailto:postgresql-
> c...@googlegroups.com] On Behalf Of Pavel Stehule
> Sent: Friday, February 08, 2013 2:24 PM
> To: postgr...@googlegroups.com
> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>

ROWS je tam default, čili 1000. Mimochodem - smysl tohoto parametru mi uniká, ta funkce může podle parametrů vracet naprosto libovolný počet řádků...

Možná mám řešení, ale říkám to zatím opatrně, chce to víc testů. Přepsal jsem ten select takto:

WITH pl AS (SELECT DISTINCT date FROM pl_sync WHERE date notnull), ps AS (SELECT ("PlaylistSection"(fid,date,date))."ID" FROM pl)
SELECT i."ID" FROM "PL_items" i JOIN "PL_station_sections" s ON s."StationID"=3 AND s."ID"=i."SSectionID" JOIN pl ON i."Date"=pl.date
WHERE i."ID" NOT IN (SELECT * FROM ps) ORDER BY "Index" DESC;

bylo:

WITH pl AS (SELECT DISTINCT date FROM pl_sync WHERE date notnull)
SELECT i."ID" FROM "PL_items" i JOIN "PL_station_sections" s ON s."StationID"=sid AND s."ID"=i."SSectionID" JOIN pl ON i."Date"=pl.date
WHERE i."ID" NOT IN (SELECT ("PlaylistSection"(fid,date,date))."ID" FROM pl) ORDER BY "Index" DESC;

Plán je pak takovýto, těch 200000 je tam pořád, nicméně je to rychlé:

Sort (cost=15982911.52..15982917.66 rows=2457 width=8) (actual time=142.091..142.092 rows=24 loops=1)

Output: i."ID", i."Index"
Sort Key: i."Index"
Sort Method: quicksort Memory: 17kB
CTE pl

-> HashAggregate (cost=291.68..293.68 rows=200 width=8) (actual time=0.303..0.319 rows=24 loops=1)
Output: pl_sync.date
-> Seq Scan on pg_temp_7.pl_sync (cost=0.00..265.65 rows=10413 width=8) (actual time=0.003..0.284 rows=24 loops=1)

Output: pl_sync.date
Filter: (pl_sync.date IS NOT NULL)
Rows Removed by Filter: 1090

CTE ps
-> CTE Scan on pl (cost=0.00..1053.00 rows=200000 width=8) (actual time=13.109..114.967 rows=126 loops=1)

Output: ("PlaylistSection"(10, pl.date, pl.date))."ID"

-> Nested Loop (cost=0.00..15981426.47 rows=2457 width=8) (actual time=125.592..142.080 rows=24 loops=1)

Output: i."ID", i."Index"
Join Filter: (i."Date" = pl.date)
Rows Removed by Join Filter: 18696

-> CTE Scan on pl (cost=0.00..4.00 rows=200 width=8) (actual time=0.305..0.309 rows=24 loops=1)
Output: pl.date
-> Materialize (cost=0.00..15974057.61 rows=2457 width=16) (actual time=4.794..5.813 rows=780 loops=24)

Output: i."ID", i."Index", i."Date"

-> Nested Loop (cost=0.00..15974045.33 rows=2457 width=16) (actual time=115.059..138.406 rows=780 loops=1)

Output: i."ID", i."Index", i."Date"

-> Seq Scan on public."PL_station_sections" s (cost=0.00..1.81 rows=6 width=4) (actual time=0.005..0.015 rows=6 loops=1)

Output: s."ID", s."StationID", s."SectionID", s."InterfaceID", s."Style"
Filter: (s."StationID" = 3)
Rows Removed by Filter: 59

-> Index Scan using "PL_items_idx" on public."PL_items" i (cost=0.00..2662334.68 rows=591 width=20) (actual time=19.192..23.039 rows=130 loops=6)

Output: i."ID", i."SSectionID", i."Date", i."Index", i."Time", i."TypeID", i."ElementID", i."Status", i."Startpos", i."Chain", i."Skip", i."Imported", i."Lock", i."Expanded", i."Runtime", i."Mixtime", i."Played", i."Volume", i."MixID", i."MixUser", i."UserCueIn", i."UserCueOut", i."UserFadeIn", i."UserFadeOut", i."Script", i."Airtime"
Index Cond: (i."SSectionID" = s."ID")

Filter: (NOT (SubPlan 3))

Rows Removed by Filter: 21

SubPlan 3
-> CTE Scan on ps (cost=0.00..4000.00 rows=200000 width=4) (actual time=0.015..0.139 rows=117 loops=906)
Output: ps."ID"
Total runtime: 142.218 ms

[Pavel Stehule]

Dne 8. února 2013 14:40 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

>> -----Original Message-----
>> From: postgr...@googlegroups.com [mailto:postgresql-
>> c...@googlegroups.com] On Behalf Of Pavel Stehule
>> Sent: Friday, February 08, 2013 2:24 PM
>> To: postgr...@googlegroups.com
>> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>>
>> Dne 8. února 2013 13:54 Jiri Skopik/8BC Ltd. <sko...@8bc.com>
>> napsal(a):
>> > SubPlan 2
>> > -> CTE Scan on pl (cost=0.00..1053.00
>> rows=200000 width=8) (actual time=5.142..93.633 rows=117 loops=906)
>> > Output: ("PlaylistSection"(10,
>> pl.date, pl.date))."ID"
>>
>>
>> Prijde mi hrozne divne, jak se pg dostane k 200 000 radkum u toho CTE
>>
>> SubPlan 2
>> -> CTE Scan on pl (cost=0.00..1053.00
>> rows=200000 width=8) (actual time=5.142..93.633 rows=117 loops=906)
>> Output: ("PlaylistSection"(10,
>> pl.date, pl.date))."ID"
>>
>> Nemate tam nastaveny ROWS u funkce PlaylistSection ??
>
> ROWS je tam default, čili 1000. Mimochodem - smysl tohoto parametru mi uniká, ta funkce může podle parametrů vracet naprosto libovolný počet řádků...

SRF funkce vraci relaci - ale k ni neni ani zakladni statistika, tj
pocet radku - ktera se skoro vsude pouziva v planeru. Defaultne je tam
1000 - tj predpoklada se, ze funkce vraci +/- neco kolem 1000 radku. V
pripade, ze bych mel funkci, ktera vraci 100K radku, ale optimalizator
by pracoval s 1K, tak dostanu totalne ustrelene odhady a nasledne
neoptimalni plan. A pripadne mi to taky muze vyzrat veskerou pamet -
viz jeden z prvnich problemu, ktere jsem u vas resil - bo se pouzije
treba hash join, ktery data uklada do pameti - ale o nekolik radu
vetsi data se tam nemohou vejit a nestesti je hotovo :). Zrovna tak
naopak pokud mam funkce, ktere vraci 10 radku, tak default 1000 muze
vest k neoptimalnimu planu a pomoci ROWS to mohu trochu korigovat.

jeste ma kazda funkce atribut COST

tady by mozna stalo za znousku zvysit cenu atributu COST u teto funkce
treba na nnasobek a zjistit, jaky to ma vliv na plan - dost mozna, ze
by se pg, snazil mene pouzivat nested loop

>
> Možná mám řešení, ale říkám to zatím opatrně, chce to víc testů. Přepsal jsem ten select takto:
>
> WITH pl AS (SELECT DISTINCT date FROM pl_sync WHERE date notnull), ps AS (SELECT ("PlaylistSection"(fid,date,date))."ID" FROM pl)
> SELECT i."ID" FROM "PL_items" i JOIN "PL_station_sections" s ON s."StationID"=3 AND s."ID"=i."SSectionID" JOIN pl ON i."Date"=pl.date
> WHERE i."ID" NOT IN (SELECT * FROM ps) ORDER BY "Index" DESC;
>
> bylo:
> WITH pl AS (SELECT DISTINCT date FROM pl_sync WHERE date notnull)
> SELECT i."ID" FROM "PL_items" i JOIN "PL_station_sections" s ON s."StationID"=sid AND s."ID"=i."SSectionID" JOIN pl ON i."Date"=pl.date
> WHERE i."ID" NOT IN (SELECT ("PlaylistSection"(fid,date,date))."ID" FROM pl) ORDER BY "Index" DESC;
>
>
> Plán je pak takovýto, těch 200000 je tam pořád, nicméně je to rychlé:

tohle vypada na bug v pg ( v odhadech) - mohl byste, pls, udelat test,
na kterem by se to dalo odsimulovat? t

ten plan je uplne stejny, jako v predchozim priklade

Nested Loop (cost=0.00..5515142.33 rows=2457 width=16) (actual

time=115.831..84855.665 rows=780 loops=1)

Output: i."ID", i."Index", i."Date"
-> Seq Scan on public."PL_station_sections" s

(cost=0.00..1.81 rows=6 width=4) (actual time=0.004..0.016 rows=6

loops=1)
Output: s."ID", s."StationID",
s."SectionID", s."InterfaceID", s."Style"
Filter: (s."StationID" = 3)
Rows Removed by Filter: 59
-> Index Scan using "PL_items_idx" on

public."PL_items" i (cost=0.00..919184.18 rows=591 width=20) (actual

time=69.053..14142.514 rows=130 loops=6)

Output: i."ID", i."SSectionID", i."Date",
i."Index", i."Time", i."TypeID", i."ElementID", i."Status",
i."Startpos", i."Chain", i."Skip", i."Imported", i."Lock",
i."Expanded", i."Runtime", i."Mixtime", i."Played", i."Volume",
i."MixID", i."MixUser", i."UserCueIn", i."UserCueOut", i."UserFadeIn",
i."UserFadeOut", i."Script", i."Airtime"
Index Cond: (i."SSectionID" = s."ID")

Filter: (NOT (SubPlan 2))

Rows Removed by Filter: 21

SubPlan 2
-> CTE Scan on pl (cost=0.00..1053.00
rows=200000 width=8) (actual time=5.142..93.633 rows=117 loops=906)
Output: ("PlaylistSection"(10,
pl.date, pl.date))."ID"

je ta pomala verze stale jeste pomala - nebylo jen docasne pretizene IO ??

diky materializaci a index scanu to muze byt podstatne citlivejsi na IO

Pavel

[Jiri Skopik/8BC Ltd.]

To bych rád, ale zatím netuším, jak to udělat, když je to takhle zažrané do systému.

Jako jestli to jenom není pocit, že je to někdy pomalé? To rozhodně ne, už se v tom hrabu druhý den a udělal jsem desítky testů na dvou různých strojích, je to pomalé/rychlé naprosto spolehlivě.

>
>
> >
> >>
> >> --
> >> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> >> PostgreSQL-cz ve Skupinách Google.
> >> Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-
> maily,
> >> zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> >> Další možnosti najdete na adrese
> >> https://groups.google.com/groups/opt_out.
> >>
> >
> > --
> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.

> > Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-
> maily, zašlete e-mail na adresu postgresql-

> cz+unsu...@googlegroups.com.

[Pavel Stehule]

Dne 8. února 2013 15:36 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

no, protoze mezi rychlym planem a pomalym planem nevidim zadny rozdil
- krome toho, ze jednou se jedna cast, ktera silne zavisi na IO
provadi nekolikanasobne pomaleji

Pavel

[Jiri Skopik/8BC Ltd.]

No já to beru, ale prostě se mi to takhle chová, nevymýšlím si to.
Nějaký důvod to mít musí...

[Pavel Stehule]

Dne 8. února 2013 16:41 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

jj něco za tím bude - ale aktuálně spíš podezírám operační systém než Postgres.

předpokládám, že to máte na dvou různých strojích - můžete prověřit,
že jsou stejné konfigurace a že rychlost zápisu a čtení na obou
systémech je stejný? Případně, jestli je to na jedné mašině, tak to
jenom potvrdit, abysme zůžili seznam podezřelých. Také bych se podíval
jestli zhruba sedí velikosti tabulek a indexů.

Pavel

[Pavel Stehule]

Ahoj

skoro to vypadá na bug Postgresu - napsal jsem test a poslal ho do konference

http://www.postgresql.org/message-id/CAFj8pRAfaCBEPfo4Zpyck1wVgShboXWA2VEY+=rGfeLD...@mail.gmail.com

Jen by mne zajímalo, jak se to může chovat rychleji - u mne je to
stabilně pomalé.

Co jsem zjistil, tak je to extrémně závislé na nastavení work_mem -
pokud je work_mem "nedostatečná", tak se naprosto ustřelí odhady a
výsledkem je plán, který je pomalý. Při zvětšení work_mem to
vygenerovalo tentýž plán jako v 9.1.

Pavel

[Jiri Skopik/8BC Ltd.]

Tu závislost na work_mem potvrzuju, ale musel jsem jít výš - 5MB je ještě málo, při 6MB už to chodí rychle.
Nezkoušel jsi tu upravenou verzi selectu? Ta mi chodí rychle bez ohledu na work_mem, byť se v plánu pořád vyskytují podezřelá čísla.

Jirka

> -----Original Message-----
> From: postgr...@googlegroups.com [mailto:postgresql-
> c...@googlegroups.com] On Behalf Of Pavel Stehule
> Sent: Saturday, February 09, 2013 10:09 AM
> To: postgr...@googlegroups.com
> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>

[Pavel Stehule]

Dne 11. února 2013 11:13 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

> Tu závislost na work_mem potvrzuju, ale musel jsem jít výš - 5MB je ještě málo, při 6MB už to chodí rychle.
> Nezkoušel jsi tu upravenou verzi selectu? Ta mi chodí rychle bez ohledu na work_mem, byť se v plánu pořád vyskytují podezřelá čísla.

vecer se na to podivam

Pavel

[Pavel Stěhule]

On 11 ún, 13:40, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> Dne 11. února 2013 11:13 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):
>
> > Tu závislost na work_mem potvrzuju, ale musel jsem jít výš - 5MB je ještě málo, při 6MB už to chodí rychle.
> > Nezkoušel jsi tu upravenou verzi selectu? Ta mi chodí rychle bez ohledu na work_mem, byť se v plánu pořád vyskytují podezřelá čísla.
>
> vecer se na to podivam

tak ta Vase rychla verze byla rychlejsi, ale stale o dost pomalejsi
nez optimalni.

Jestli jsem to spravne pochopil, a priznam se, ze mi model odhadu CTE
neni uplne jasny, tak jadro pudla je spatnem nastaveni atributu ROWS -
9.1 byla hloupa, a nesnazila se o pouziti statistik, 9.2 je chytrejsi,
ale vzhledem k tomu, ze ROWS je nastevene prilis vysoko, tak jsou pak
odhady prilis vysoke a to vyzaduje hodne work_mem by se chytil hash
join. Kolik tak typicky vraci radku funkce PlaylistSection?

>
> Pavel
>
>
>
>
>
>
>
>
>
> > Jirka
>
> >> -----Original Message-----
> >> From: postgr...@googlegroups.com [mailto:postgresql-
> >> c...@googlegroups.com] On Behalf Of Pavel Stehule
> >> Sent: Saturday, February 09, 2013 10:09 AM
> >> To: postgr...@googlegroups.com
> >> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>
> >> Ahoj
>
> >> skoro to vypadá na bug Postgresu - napsal jsem test a poslal ho do
> >> konference
>
> >>http://www.postgresql.org/message-

> >> id/CAFj8pRAfaCBEPfo4Zpyck1wVgShboXWA2VEY+=rGfeLDgUQ...@mail.gmail.com

[Pavel Stěhule]

uz zacinam trochu chapat tu logiku

postgres=# explain with pl as (select distinct a from x)
select foo(a) from pl;
QUERY PLAN
───────────────────────────────────────────────────────────────────
CTE Scan on pl (cost=18.39..486.98 rows=89000 width=4)
CTE pl
-> HashAggregate (cost=17.50..18.39 rows=89 width=4)
-> Seq Scan on x (cost=0.00..15.00 rows=1000 width=4)
(4 rows)

tady je extremne dulezite, aby ROWS u SRF funkce bylo adekvatni, kdyz
se to pouzije takto.

[Jiri Skopik/8BC Ltd.]

> -----Original Message-----
> From: postgr...@googlegroups.com [mailto:postgresql-
> c...@googlegroups.com] On Behalf Of Pavel Stěhule
> Sent: Monday, February 11, 2013 8:28 PM
> To: PostgreSQL-cz
> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>
>
>

> On 11 ún, 13:40, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> > Dne 11. února 2013 11:13 Jiri Skopik/8BC Ltd. <sko...@8bc.com>
> napsal(a):
> >
> > > Tu závislost na work_mem potvrzuju, ale musel jsem jít výš - 5MB je
> ještě málo, při 6MB už to chodí rychle.
> > > Nezkoušel jsi tu upravenou verzi selectu? Ta mi chodí rychle bez
> ohledu na work_mem, byť se v plánu pořád vyskytují podezřelá čísla.
> >
> > vecer se na to podivam
>
> tak ta Vase rychla verze byla rychlejsi, ale stale o dost pomalejsi
> nez optimalni.
>

Zajímavé, mně ta upravená verze běhá stejně rychle, jako ta původní v 9.1, tedy 100-150ms...

> Jestli jsem to spravne pochopil, a priznam se, ze mi model odhadu CTE
> neni uplne jasny, tak jadro pudla je spatnem nastaveni atributu ROWS -
> 9.1 byla hloupa, a nesnazila se o pouziti statistik, 9.2 je chytrejsi,
> ale vzhledem k tomu, ze ROWS je nastevene prilis vysoko, tak jsou pak
> odhady prilis vysoke a to vyzaduje hodne work_mem by se chytil hash
> join. Kolik tak typicky vraci radku funkce PlaylistSection?

Ta funkce má v parametrech časový interval, takže v podstatě může vrátit zcela libovolný počet řádků, nicméně v tomto případě ji volám ho hodinách a to vrací jednotky řádků, maximálně pár desítek.

> > >> Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-
> maily,
> > >> zašlete e-mail na adresu postgresql-
> cz+unsu...@googlegroups.com.

> > >> Další možnosti najdete na adrese
> > >>https://groups.google.com/groups/opt_out.
> >
> > > --
> > > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.

> > > Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-
> maily, zašlete e-mail na adresu postgresql-
> cz+unsu...@googlegroups.com.

> > > Další možnosti najdete na
> adresehttps://groups.google.com/groups/opt_out.
>

[Pavel Stehule]

Dne 12. února 2013 13:32 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

>
>> -----Original Message-----
>> From: postgr...@googlegroups.com [mailto:postgresql-
>> c...@googlegroups.com] On Behalf Of Pavel Stěhule
>> Sent: Monday, February 11, 2013 8:28 PM
>> To: PostgreSQL-cz
>> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>>
>>
>>
>> On 11 ún, 13:40, Pavel Stehule <pavel.steh...@gmail.com> wrote:
>> > Dne 11. února 2013 11:13 Jiri Skopik/8BC Ltd. <sko...@8bc.com>
>> napsal(a):
>> >
>> > > Tu závislost na work_mem potvrzuju, ale musel jsem jít výš - 5MB je
>> ještě málo, při 6MB už to chodí rychle.
>> > > Nezkoušel jsi tu upravenou verzi selectu? Ta mi chodí rychle bez
>> ohledu na work_mem, byť se v plánu pořád vyskytují podezřelá čísla.
>> >
>> > vecer se na to podivam
>>
>> tak ta Vase rychla verze byla rychlejsi, ale stale o dost pomalejsi
>> nez optimalni.
>>
>
> Zajímavé, mně ta upravená verze běhá stejně rychle, jako ta původní v 9.1, tedy 100-150ms...

tam hodne zalezi na testovacich datech

>
>
>> Jestli jsem to spravne pochopil, a priznam se, ze mi model odhadu CTE
>> neni uplne jasny, tak jadro pudla je spatnem nastaveni atributu ROWS -
>> 9.1 byla hloupa, a nesnazila se o pouziti statistik, 9.2 je chytrejsi,
>> ale vzhledem k tomu, ze ROWS je nastevene prilis vysoko, tak jsou pak
>> odhady prilis vysoke a to vyzaduje hodne work_mem by se chytil hash
>> join. Kolik tak typicky vraci radku funkce PlaylistSection?
>
> Ta funkce má v parametrech časový interval, takže v podstatě může vrátit zcela libovolný počet řádků, nicméně v tomto případě ji volám ho hodinách a to vrací jednotky řádků, maximálně pár desítek.
>

v tom pripade bych zkusil nastavit ROWS u teto funkce na 50 nebo 100

Pavel

[Jiri Skopik/8BC Ltd.]

> -----Original Message-----
> From: postgr...@googlegroups.com [mailto:postgresql-
> c...@googlegroups.com] On Behalf Of Pavel Stehule
> Sent: Tuesday, February 12, 2013 1:44 PM
> To: postgr...@googlegroups.com
> Subject: Re: Zpomalení o 3 řády po přechodu na PG 9.2
>

Aha, to pomůže. Ovšem jindy tahle funkce opravdu může vracet tisíce řádků, takže se zas může vyskytnout opačný problém.
Nedá se to nastavená hodnota "přebít" jinou až při volání?

Jirka

> >> zašlete e-mail na adresu postgresql-c...@googlegroups.com.
> >> Další možnosti najdete na adrese
> >> https://groups.google.com/groups/opt_out.
> >>
> >
> > --
> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.

> > Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-
> maily, zašlete e-mail na adresu postgresql-
> cz+unsu...@googlegroups.com.
> > Další možnosti najdete na adrese
> https://groups.google.com/groups/opt_out.
> >
> >
>
> --
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> PostgreSQL-cz ve Skupinách Google.

[Pavel Stehule]

Dne 12. února 2013 14:29 Jiri Skopik/8BC Ltd. <sko...@8bc.com> napsal(a):

To muze byt problem - pokud to muze byt az takhle variabilni, tak bych
to spis honil pres docasnou tabulku - i kdyz ta to samozrejme cele
zpomali :(

a nebo si dostatecne nadimenzoval work_mem, by se chytal hash_join s
dostatecnou rezervou.

Pavel