unreliable behaviour of track_functions

From: pinker <pinker(at)onet(dot)eu>
To: pgsql-general(at)postgresql(dot)org
Subject: unreliable behaviour of track_functions
Date: 2018-03-31 23:40:43
Message-ID: 1522539643653-0.post@n3.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi All!

I've been experimenting with track_functions options and what I've saw it's
really puzzling me.
Documentation says:
/ SQL-language functions that are simple enough to be "inlined" into the
calling query will not be tracked, regardless of this setting./

But it came up, it depends on much more factors, like duration or placing it
in the query, it is totally non-deterministic behaviour.

This really simple SQL function:
CREATE FUNCTION a(a bigint)
RETURNS bigint
STABLE
LANGUAGE SQL
AS $$
SELECT $1
$$;

Is not shown in the pg_stat_user_functions at all. It is started to be shown
when one line:
select pg_sleep(1);

is added???

Another one, gets tracked only if I use:
SELECT get_unique_term(2556);

If it lands in FROM then it's not tracked...
SELECT * FROM get_unique_term(2556);

That's the body of the function:
CREATE FUNCTION get_unique_term(i_game_pin bigint)
RETURNS TABLE(term text, category text)
STABLE
LANGUAGE SQL
AS $$
SELECT
i.term,
i.dict_category_id
FROM (SELECT
categories.term,
categories.dict_category_id
FROM categories
EXCEPT ALL
SELECT
games.term,
games.category
FROM games
WHERE game_pin = $1) i
ORDER BY (random())
LIMIT 1;
$$;

What's going on here? That's pretty unreliable behaviour...

My version of postgres:
PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.3
20140911 (Red Hat 4.8.3-9), 64-bit

show track_functions;
track_functions
-----------------
all
(1 wiersz)

--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2018-03-31 23:59:56 Re: unreliable behaviour of track_functions
Previous Message Radoslav Nedyalkov 2018-03-31 18:49:32 is pg_advisory_lock() suitable for long runs