| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: pl/pgsql functions outperforming sql ones? |
| Date: | 2012-01-28 06:37:36 |
| Message-ID: | CAFj8pRCceGDEp1sxvMoe0oaio6P=O2nJPfs9MWgu4-+zCTdrVg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
2012/1/27 Carlo Stonebanks <stonec(dot)register(at)sympatico(dot)ca>:
> Yes, I did test it - i.e. I ran the functions on their own as I had always
> noticed a minor difference between EXPLAIN ANALYZE results and direct query
> calls.
>
> Interesting, so sql functions DON'T cache plans? Will plan-caching be of any
> benefit to SQL that makes no reference to any tables? The SQL is emulating
> the straight non-set-oriented procedural logic of the original plpgsql.
>
It is not necessary usually - simple SQL functions are merged to outer
query - there are e few cases where this optimization cannot be
processed and then there are performance lost.
For example this optimization is not possible (sometimes) when some
parameter is volatile
Regards
Pavel Stehule
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jayashankar K B | 2012-01-28 17:11:53 | Re: Postgress is taking lot of CPU on our embedded hardware. |
| Previous Message | Scott Marlowe | 2012-01-28 03:07:31 | Re: Postgress is taking lot of CPU on our embedded hardware. |