Re: prepared statements und partitionierte tabellen ...

Moin,

hab a bissl a Problem:

partitionierte Tabelle mit einer Spalte, nennen wir sie DATUM. Nach der
tagesweise partitioniert. Pro Tag so 2-3 Mio Datesätze. Ist ein
timestamp without timezone.

Abfragen der Art: select * from foo where datum between ts1 and ts2;

gehen super flott. (ts1 und t2 sind zu 99% immer am selben Tag, nur
Sekunden auseinander)

Aber: Kunde hat da einen $Mapper, der bastelt prepared Statements, und
ballert diese ab. Performance grottig, da Planner da beim Planen keinen
Plan (toll, ne?) von den Parametern hat. verständlich.

Kunde sagt, er hat keinen Einfluß, ist immer prepared.

Also hab ich eine stored proc geschrieben, die er aufruft. Innerhalb
mache ich ein EXECUTE 'select ...', somit wollte ich erzwingen, daß der
Plan bei Ausführung erstellt wird. Ausführungszeit gleichbleibend
grottig, obwohl er doch einklich den Plan beim EXECUTE sich basteln
müßte, mit aktuellen Parametern?

Wo ist mein Hirnknoten?

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

Hallo Andreas,

Am 23.06.2012 18:52, schrieb Andreas Kretschmer:
>
> Wo ist mein Hirnknoten?

Welche Version? 9.0 oder 9.1?

Susanne

--
Dipl. Inf. Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com

Susanne Ebrecht <susanne(at)2ndquadrant(dot)com> wrote:

> Hallo Andreas,
>
> Am 23.06.2012 18:52, schrieb Andreas Kretschmer:
>>
>> Wo ist mein Hirnknoten?
>
> Welche Version? 9.0 oder 9.1?

9.1

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°

Andreas Kretschmer schrieb:
> hab a bissl a Problem:
>
> partitionierte Tabelle mit einer Spalte, nennen wir sie DATUM. Nach der
> tagesweise partitioniert. Pro Tag so 2-3 Mio Datesätze. Ist ein
> timestamp without timezone.
>
>
> Abfragen der Art: select * from foo where datum between ts1 and ts2;
>
> gehen super flott. (ts1 und t2 sind zu 99% immer am selben Tag, nur
> Sekunden auseinander)
>
>
> Aber: Kunde hat da einen $Mapper, der bastelt prepared Statements, und
> ballert diese ab. Performance grottig, da Planner da beim Planen keinen
> Plan (toll, ne?) von den Parametern hat. verständlich.
>
> Kunde sagt, er hat keinen Einfluß, ist immer prepared.
>
> Also hab ich eine stored proc geschrieben, die er aufruft. Innerhalb
> mache ich ein EXECUTE 'select ...', somit wollte ich erzwingen, daß der
> Plan bei Ausführung erstellt wird. Ausführungszeit gleichbleibend
> grottig, obwohl er doch einklich den Plan beim EXECUTE sich basteln
> müßte, mit aktuellen Parametern?
>
> Wo ist mein Hirnknoten?

Kann ich nicht sagen, aber ich würde mir einmal die Pläne anschauen.

Verwende auto_explain mit
auto_explain.log_nested_statements = on
und
auto_explain.log_min_duration = 0

Dann wirst Du die Ausführungspläne im Log sehen.
Vielleicht kann man dann mehr sagen.

Du verwendest eh nicht EXECUTE ... USING, oder?

Liebe Grüße,
Laurenz Albe

> -----Ursprüngliche Nachricht-----
> Von: pgsql-de-allgemein-owner(at)postgresql(dot)org [mailto:pgsql-de-allgemein-
> owner(at)postgresql(dot)org] Im Auftrag von Albe Laurenz
> Gesendet: Montag, 25. Juni 2012 09:50
> An: Andreas Kretschmer *EXTERN*; pgsql-de-allgemein(at)postgresql(dot)org
> Betreff: Re: [pgsql-de-allgemein] prepared statements und partitionierte
> tabellen ...
>
> Andreas Kretschmer schrieb:
> > hab a bissl a Problem:
> >
> > partitionierte Tabelle mit einer Spalte, nennen wir sie DATUM. Nach
> der
> > tagesweise partitioniert. Pro Tag so 2-3 Mio Datesätze. Ist ein
> > timestamp without timezone.
> >
> >
> > Abfragen der Art: select * from foo where datum between ts1 and ts2;
> >
> > gehen super flott. (ts1 und t2 sind zu 99% immer am selben Tag, nur
> > Sekunden auseinander)
> >
> >
> > Aber: Kunde hat da einen $Mapper, der bastelt prepared Statements, und
> > ballert diese ab. Performance grottig, da Planner da beim Planen
> keinen
> > Plan (toll, ne?) von den Parametern hat. verständlich.
> >
> > Kunde sagt, er hat keinen Einfluß, ist immer prepared.
> >
> > Also hab ich eine stored proc geschrieben, die er aufruft. Innerhalb
> > mache ich ein EXECUTE 'select ...', somit wollte ich erzwingen, daß
> der
> > Plan bei Ausführung erstellt wird. Ausführungszeit gleichbleibend
> > grottig, obwohl er doch einklich den Plan beim EXECUTE sich basteln
> > müßte, mit aktuellen Parametern?
> >
> > Wo ist mein Hirnknoten?
>
> Kann ich nicht sagen, aber ich würde mir einmal die Pläne anschauen.
>
> Verwende auto_explain mit
> auto_explain.log_nested_statements = on
> und
> auto_explain.log_min_duration = 0
>
> Dann wirst Du die Ausführungspläne im Log sehen.
> Vielleicht kann man dann mehr sagen.
>
> Du verwendest eh nicht EXECUTE ... USING, oder?

Doch, hab das mit USING gemacht. Keine gute Idee? Im Plan (händisch die
Funktion aufgerufen)

Das Explain für das Select selbst (also innerhalb der Funktion) ist okay,
Zeit:
(actual time=0.019..0.020 rows=1 loops=1)

Aber der Aufruf der Funktion selber:
(actual time=164.628..164.628 rows=1 loops=1)

Mit freundlichen Grüssen

Andreas Kretschmer
- Technik -

--
HINWEIS: Der internet24-Support arbeitet im Team -
bitte senden Sie daher immer die komplette Mailkommunikation mit.

-------------------------------------------------
internet24 GmbH Bayrische Str. 18 D-01069 Dresden
Fon : +49 (0)3 51 / 2 11 20 30
Fax : +49 (0)3 51 / 2 11 20 20
E-Mail : kretschmer(at)internet24(dot)de
Facebook: internet24gmbh
URL : www.internet24.de
Blog : blog.internet24.de

Geschäftsführer: Heiko Heerwagen
Registergericht: Amtsgericht Dresden HRB 12 899

Andreas Kretschmer schrieb:
>>> Wo ist mein Hirnknoten?

>> Kann ich nicht sagen, aber ich würde mir einmal die Pläne anschauen.

>> Du verwendest eh nicht EXECUTE ... USING, oder?

> Doch, hab das mit USING gemacht. Keine gute Idee?

Nein, das ist eh ok.

Ich hatte nur, ohne nachzuprüfen, vermutet, daß dann vielleicht
ein parametriertes Statement verwendet wird.

Ein kurzer Test hat aber ergeben, daß die Konstante in die Abfrage
eingebaut wird. Das beobachtest Du wahrscheinlich auch im
Output von auto_explain.

> Im Plan (händisch die
> Funktion aufgerufen)
>
> Das Explain für das Select selbst (also innerhalb der Funktion) ist okay,
> Zeit:
> (actual time=0.019..0.020 rows=1 loops=1)
>
> Aber der Aufruf der Funktion selber:
> (actual time=164.628..164.628 rows=1 loops=1)

Was passiert denn sonst noch in der Funktion?

Kannst Du das CREATE FUNCTION-Statement schicken?

Liebe Grüße,
Laurenz Albe

Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> wrote:

> Andreas Kretschmer schrieb:
> >>> Wo ist mein Hirnknoten?
>
> >> Kann ich nicht sagen, aber ich würde mir einmal die Pläne anschauen.
>
> >> Du verwendest eh nicht EXECUTE ... USING, oder?
>
> > Doch, hab das mit USING gemacht. Keine gute Idee?
>
> Nein, das ist eh ok.
>
> Ich hatte nur, ohne nachzuprüfen, vermutet, daß dann vielleicht
> ein parametriertes Statement verwendet wird.
>
> Ein kurzer Test hat aber ergeben, daß die Konstante in die Abfrage
> eingebaut wird. Das beobachtest Du wahrscheinlich auch im
> Output von auto_explain.
>
> > Im Plan (händisch die
> > Funktion aufgerufen)
> >
> > Das Explain für das Select selbst (also innerhalb der Funktion) ist okay,
> > Zeit:
> > (actual time=0.019..0.020 rows=1 loops=1)
> >
> > Aber der Aufruf der Funktion selber:
> > (actual time=164.628..164.628 rows=1 loops=1)
>
> Was passiert denn sonst noch in der Funktion?
>
> Kannst Du das CREATE FUNCTION-Statement schicken?

Sorry für die späte Antwort - das Problem hat sich erst mal erledigt,
der $KUNDE gibt jetzt im SELECT schon gleich die korrekte Tabelle an.

War ein paar Tage jetzt a bissl stressig, aber der Kunde hat nun auch
verstanden, daß er seine Statements anpassen kann, und damit *richtig*
er was gewinnt.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°