From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Andy Halsall <halsall_andy(at)hotmail(dot)com> |
Cc: | "postgresql (dot)org novice list" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Function Scan costs |
Date: | 2012-06-27 23:33:51 |
Message-ID: | 1340840031.32226.12.camel@sussancws0025 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Wed, 2012-06-27 at 15:56 +0000, Andy Halsall wrote:
> I'm calling functions via libpq. I've noticed that in the EXPLAIN
> analysis the time for the Function Scan is high relative to that of
> the actual query. In the example below (if I'm reading it correctly),
> the query seems to take just 0.022 ms whereas the time allocated to
> "Function Scan is 0.483ms. Is this to do with parsing original query
> and substituting params? Could somebody please explain? Thanks.
The times involved are quite small so it's hard to speculate on exactly
what's causing the difference (if there is a real difference).
If I had to guess, I would say that it's because a set-returning
function (SRF) always materializes the entire result. That's a
limitation of SRFs, and you might consider a foreign table instead if it
suits your needs.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Antonio Carlos Salzvedel Furtado Junior | 2012-06-28 10:17:51 | Re: The use of cpu_index_tuple_cost by the query planner |
Previous Message | Jeff Davis | 2012-06-27 23:22:06 | Re: The use of cpu_index_tuple_cost by the query planner |