Thanks, I went into that function, added log statements everywhere and
figured which check it's failing on:
!heap_attisnull(func_tuple, Anum_pg_proc_proconfig)
and it's because my real function had this at the end:
SET search_path FROM CURRENT;
which I never imagined would make any
Evan Martin postgre...@realityexists.net writes:
Thanks, I went into that function, added log statements everywhere and
figured which check it's failing on:
!heap_attisnull(func_tuple, Anum_pg_proc_proconfig)
and it's because my real function had this at the end:
SET search_path FROM
Of course, it seems silly now to not have included SET search_path FROM
current in my post, but I had no idea what was and wasn't critical -
that was the whole problem. Wisdom begins with knowing the right
questions to ask! Yes, I was looking at the same function - even checked
SVN logs to
OK, it's now changed back again! I suspended the virtual machine in
which PostgreSQL runs, later resumed it, did some unrelated queries
(SELECT only) and then ran the exact same query as before. It now
returns in 15 ms and uses the index. Here's the query plan:
Index Scan using
Evan Martin postgre...@realityexists.net writes:
This worked... at first. I did some simple queries and they showed the
function being inlined (index scan on primary key, seq scan - no
function scan). Very happy with that, I tried changing some other
functions (that depend on these) and
Some of my functions are running much slower than doing the same query
inline and I'd like to know if there's a way to fix that.
I have a number of tables that store data valid at different times. For
each logical entity there may be multiple rows, valid at different times
(sometimes
On Wed, May 2, 2012 at 12:43 PM, Evan Martin
postgre...@realityexists.net wrote:
Some of my functions are running much slower than doing the same query
inline and I'd like to know if there's a way to fix that.
[chomp analysis and examples]
Is there any possibility that you could recode your
Evan Martin postgre...@realityexists.net writes:
Some of my functions are running much slower than doing the same query
inline and I'd like to know if there's a way to fix that. ...
This is quite slow, especially when I have a WHERE clause that narrows
down the set of rows from 100,000 to 10
Thanks, Tom (and Chris). Yes, the EXPLAIN output showed a function scan:
SELECT * FROM thing_asof('2012-04-01') WHERE timeslice_id = 1234
Function Scan on thing_asof (cost=0.25..12.75 rows=5 width=353)
Filter: ((timeslice_id)::integer = 12345)
I replaced the OVERLAPS with and = comparisons
