| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | fche(at)redhat(dot)com (Frank Ch(dot) Eigler) |
| Cc: | Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Query much slower when run from postgres function |
| Date: | 2009-03-10 17:20:47 |
| Message-ID: | 355.1236705647@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc pgsql-performance |
fche(at)redhat(dot)com (Frank Ch. Eigler) writes:
> For a prepared statement, could the planner produce *several* plans,
> if it guesses great sensitivity to the parameter values? Then it
> could choose amongst them at run time.
We've discussed that in the past. "Choose at runtime" is a bit more
easily said than done though --- you can't readily flip between plan
choices part way through, if you've already emitted some result rows.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kris Jurka | 2009-03-10 17:35:38 | Re: a possible bug in postgresql jdbc driver |
| Previous Message | Kris Jurka | 2009-03-10 16:55:24 | Re: [PERFORM] Query much slower when run from postgres function |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2009-03-10 17:50:05 | Re: When does sequential performance matter in PG? |
| Previous Message | Kris Jurka | 2009-03-10 16:55:24 | Re: [PERFORM] Query much slower when run from postgres function |