Subject: Re: Index ignored on pkid = curval('some_seq'), used with pkid =
 (select curval(''some_seq') )
To: pgsql-admin@lists.postgresql.org
References: <0ee1a3a2-7394-d518-2e22-790a84ef558c@matrix.gatewaynet.com>
 <14554.1551280909@sss.pgh.pa.us>
From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Message-ID: <650a8870-5047-8adf-451e-45d8b5237de0@matrix.gatewaynet.com>
Date: Thu, 28 Feb 2019 12:25:34 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: <14554.1551280909@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

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