pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedIndex ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') )
3+ messages / 2 participants
[nested] [flat]
* Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') )
@ 2019-02-27 08:54 Achilleas Mantzios <achill@matrix.gatewaynet.com>
0 siblings, 1 reply; 3+ messages in thread
From: Achilleas Mantzios @ 2019-02-27 08:54 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
On Postgresql 10 and 11
begin;
insert into itemshist(id,repdate,systemdate,done,username) VALUES(1454349,current_date,current_timestamp,'t','foo');
dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = currval(('public.itemshist_pkid_seq'::text)::regclass);
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
Update on itemshist (cost=0.00..412082.16 rows=1 width=167) (actual time=15833.238..15833.238 rows=0 loops=1)
-> Seq Scan on itemshist (cost=0.00..412082.16 rows=1 width=167) (actual time=14444.143..15833.210 rows=1 loops=1)
Filter: (pkid = currval(('public.itemshist_pkid_seq'::text)::regclass))
Rows Removed by Filter: 14470046
Planning Time: 0.095 ms
Trigger for constraint $1: time=0.240 calls=1
Trigger itemshist_dbmirror_trig: time=3.101 calls=1
Execution Time: 15836.636 ms
(8 rows)
-- but if I compare against select currval it uses the index:
dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = ( SELECT currval(('public.itemshist_pkid_seq'::text)::regclass));
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
Update on itemshist (cost=0.45..8.47 rows=1 width=167) (actual time=0.048..0.048 rows=0 loops=1)
InitPlan 1 (returns $0)
-> Result (cost=0.00..0.01 rows=1 width=8) (actual time=0.006..0.006 rows=1 loops=1)
-> Index Scan using itemshist_pkey on itemshist (cost=0.43..8.45 rows=1 width=167) (actual time=0.028..0.033 rows=1 loops=1)
Index Cond: (pkid = $0)
Planning Time: 0.095 ms
Trigger for constraint $1: time=0.145 calls=1
Trigger itemshist_dbmirror_trig: time=3.026 calls=1
Execution Time: 3.273 ms
(9 rows)
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') )
@ 2019-02-27 15:21 Tom Lane <tgl@sss.pgh.pa.us>
parent: Achilleas Mantzios <achill@matrix.gatewaynet.com>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2019-02-27 15:21 UTC (permalink / raw)
To: Achilleas Mantzios <achill@matrix.gatewaynet.com>; +Cc: pgsql-admin@lists.postgresql.org
Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
> dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = currval(('public.itemshist_pkid_seq'::text)::regclass);
currval() is marked volatile, so that's not a legal index
qualification.
(Perhaps there's an argument that it'd be more useful to consider it
stable, but certainly if you used it in the same query as a nextval()
on the same sequence, you'd have trouble.)
> -- but if I compare against select currval it uses the index:
> dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = ( SELECT currval(('public.itemshist_pkid_seq'::text)::regclass));
Yeah, the planner does not consider uncorrelated scalar sub-selects
to be volatile; they'll be evaluated only once per query, regardless
of what they contain. So this is sort of a traditional hack for
freezing a volatile function's result. (I have no idea whether other
RDBMSes read the SQL spec the same way on this point.)
regards, tom lane
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') )
@ 2019-02-28 10:25 Achilleas Mantzios <achill@matrix.gatewaynet.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Achilleas Mantzios @ 2019-02-28 10:25 UTC (permalink / raw)
To: pgsql-admin@lists.postgresql.org
On 27/2/19 5:21 μ.μ., Tom Lane wrote:
> Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
>> dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = currval(('public.itemshist_pkid_seq'::text)::regclass);
> currval() is marked volatile, so that's not a legal index
> qualification.
>
> (Perhaps there's an argument that it'd be more useful to consider it
> stable, but certainly if you used it in the same query as a nextval()
> on the same sequence, you'd have trouble.)
>
>> -- but if I compare against select currval it uses the index:
>> dynacom=# explain analyze update itemshist set reason='{foo,bar}' where pkid = ( SELECT currval(('public.itemshist_pkid_seq'::text)::regclass));
> Yeah, the planner does not consider uncorrelated scalar sub-selects
> to be volatile; they'll be evaluated only once per query, regardless
> of what they contain. So this is sort of a traditional hack for
> freezing a volatile function's result. (I have no idea whether other
> RDBMSes read the SQL spec the same way on this point.)
Thanks Tom.
>
> regards, tom lane
>
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2019-02-28 10:25 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-02-27 08:54 Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') ) Achilleas Mantzios <achill@matrix.gatewaynet.com>
2019-02-27 15:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2019-02-28 10:25 ` Achilleas Mantzios <achill@matrix.gatewaynet.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox