Re: Trigger function, bad performance

From: "Rogatzki Rainer" <rainer(dot)rogatzki(at)ggrz-hagen(dot)nrw(dot)de>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Trigger function, bad performance
Date: 2008-12-05 15:41:14
Message-ID: 595F977C01388944A4B5158975BB676385ACA8@sgzhmailbox.ggrz-hagen.nrw.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Laurenz Albe wrote:
> You have been ordered to use a partial index?
>
> > Apart from this I don't really understand why statement preparation
> > combined with parameters in functions prevent index invocation.
> > Especially since p_id_user is a parameter as well which doesn't
> > prevent the usage of another existing index on costs.id_user and
costs.id_state.
>
> The connection with parameters is by chance.
>
> The main thing is that both "p_begin" and "p_until" are variables.
>
> Andreas Kretschmer gave you the advice you'll want: use dynamic SQL.
>
> Yours,
> Laurenz Albe
Well it was no 'order' to use a partial index but it was necessary,
since the table is vastly filled with log-entries that have to persist
over 4 years for documentation. Since old entries are accessed and
changed less often we decided to introduce partial indexes for a better
performance. This prooved to speed up especially frequently used monthly
reports.

Now I understand (thanks to Andreas Kretschmer and you) that at
execution planning time postgres cannot decide what partial index to use
for following procedure calls and thus doesn't invoke it.

After implementing Andreas' proposal (execute 'my statement') the
expected index is used and performance is 125 time better :O))

Best regards
Rainer Rogatzki

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2008-12-05 22:42:03 Re: Context switch storms
Previous Message Albe Laurenz 2008-12-05 15:16:37 Re: Trigger function, bad performance