Re: Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') )

From: Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)com>
To: pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: Index ignored on pkid = curval('some_seq'), used with pkid = (select curval(''some_seq') )
Date: 2019-02-28 10:25:34
Message-ID: 650a8870-5047-8adf-451e-45d8b5237de0@matrix.gatewaynet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On 27/2/19 5:21 μ.μ., Tom Lane wrote:
> Achilleas Mantzios <achill(at)matrix(dot)gatewaynet(dot)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

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Pepe TD Vo 2019-02-28 14:26:33 Re: [MASSMAIL]Re: pg_dumpall: could not connect to database: FATAL
Previous Message Ashok Kumar Tiwari 2019-02-28 07:24:55 Re: org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.