| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Federico /* juri */ Pedemonte <fepede(at)inwind(dot)it> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: for/loop performance in plpgsql ? |
| Date: | 2002-11-19 14:04:02 |
| Message-ID: | 20274.1037714642@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Federico /* juri */ Pedemonte <fepede(at)inwind(dot)it> writes:
> On Tue, Nov 19, 2002 at 12:23:56AM -0500, Tom Lane wrote:
>> The planner has to fall back to default selectivity estimates when it's
>> looking at queries involving plpgsql variables (since it can't know
>> their actual values in advance). I suspect your problem is related to
>> an inaccurate default estimate.
> mmm... does it mean that i can't do anything about that ?
A brute-force solution is to use EXECUTE so that the query is re-planned
each time, with the planner seeing constants instead of variables
compared to the column values.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jirka Novak | 2002-11-19 14:26:09 | Slow DELETE with IN clausule |
| Previous Message | Rod Taylor | 2002-11-19 13:46:39 | Re: [HACKERS] Question regarding effects of Vacuum, Vacuum |