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
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 |