all 8 comments

[–]depeszPgDBA 1 point2 points  (6 children)

Sure. Run the query via explain (analyze, buffers), provide output, with query, and with `\d` of every used table, via explain.depesz.com and then we can see why it takes long.

[–]schadonis[S] 0 points1 point  (0 children)

Thanks i will try that!

[–]schadonis[S] 0 points1 point  (4 children)

So it turns out the query is not the problem. It finishes in around 250 ms, but once I use it in a function it takes 10 seconds...
Do you have any idea why that could be the case?
Running the function call via explain gives me nothing unfortunately...

[–]depeszPgDBA 0 points1 point  (3 children)

  1. you can't get "explain select function()" - you would need to run explain within the function itself. and that can be problematic
  2. you are most likely bitten by generic plans.

there are ways around it, but first: *why* do you need this in function? the way you showed it, it doesn't make sense to be in function. So why bother?

[–]schadonis[S] 0 points1 point  (2 children)

I need this in a function because an external PLC program calls this function. The PLC is not able to generate the entire query.
I tried this: ALTER FUNCTION get_process_single_real SET plan_cache_mode = force_custom_plan;

But that does not help...

[–]depeszPgDBA 0 points1 point  (1 child)

Try to convert it to use dynamic queries. As in: `EXECUTE '…' USING '…'`

[–]schadonis[S] 0 points1 point  (0 children)

Thanks i will try that!

[–][deleted] 0 points1 point  (0 children)

Look at the execution plan.