Re: prepared statements und partitionierte tabellen ...

From: "Andreas Kretschmer - internet24 GmbH" <kretschmer(at)internet24(dot)de>
To: "'Albe Laurenz'" <laurenz(dot)albe(at)wien(dot)gv(dot)at>, "'Andreas Kretschmer *EXTERN*'" <akretschmer(at)spamfence(dot)net>, <pgsql-de-allgemein(at)postgresql(dot)org>
Subject: Re: prepared statements und partitionierte tabellen ...
Date: 2012-06-25 23:04:30
Message-ID: 010201cd5326$e0cf0a20$a26d1e60$@internet24.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein


> -----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

In response to

Responses

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Albe Laurenz 2012-06-26 10:29:35 Re: prepared statements und partitionierte tabellen ...
Previous Message Albe Laurenz 2012-06-25 07:50:06 Re: prepared statements und partitionierte tabellen ...