Re: Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') )
От | Tom Lane |
---|---|
Тема | Re: Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') ) |
Дата | |
Msg-id | 14554.1551280909@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Index ignored on pkid = curval('some_seq'), used with pkid = (selectcurval(''some_seq') ) (Achilleas Mantzios <achill@matrix.gatewaynet.com>) |
Ответы |
Re: Index ignored on pkid = curval('some_seq'), used with pkid =(select curval(''some_seq') )
|
Список | pgsql-admin |
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
В списке pgsql-admin по дате отправления: