From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Federico <fepede(at)inwind(dot)it> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: for/loop performance in plpgsql ? |
Date: | 2002-11-19 05:23:56 |
Message-ID: | 17928.1037683436@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Federico <fepede(at)inwind(dot)it> writes:
>> Well - the query might well be pre-parsed which means it wouldn't notice any
>> updated stats. Can you provide an example of your code?
> It's nothing particular strange. It's something like :
> result record;
> for result in select rai, tem
> from data
> where (codice LIKE cod_staz and
> ora > orain and
> ora <= orafin) loop
Which of these names are columns of the selected tables, and which ones
are plpgsql variables?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Federico /* juri */ Pedemonte | 2002-11-19 09:49:26 | Re: for/loop performance in plpgsql ? |
Previous Message | Adrian Calvin | 2002-11-19 03:02:40 | Question regarding effects of Vacuum, Vacuum Analyze, and Reindex |