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 ma
Evan Martin 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 CURRENT;
Well, shame on you f
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 difference
Evan Martin 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 then found that the _asof fu
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 pk_thing_timesl
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 <= comparison
Evan Martin 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 or so. I suspect it's
On Wed, May 2, 2012 at 12:43 PM, Evan Martin
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 functions as
views? The op
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 overlap
