key = currval('tab_key_seq') choses SEQSCAN?! - Mailing list pgsql-general

From Brandon Craig Rhodes
Subject key = currval('tab_key_seq') choses SEQSCAN?!
Date
Msg-id vwy8qq3jz0.fsf@guinness.ts.gatech.edu
Whole thread Raw
Responses Re: key = currval('tab_key_seq') choses SEQSCAN?!  (Martin Marques <martin@bugs.unl.edu.ar>)
Re: key = currval('tab_key_seq') choses SEQSCAN?!  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
I have a large table (named "changes") which is perfectly willing to
support index lookups when its primary key (named "change") is
compared to a constant integer:

# explain select * from changes where change = 42;
                                 QUERY PLAN
-----------------------------------------------------------------------------
 Index Scan using changes_pkey on changes  (cost=0.00..3.01 rows=1 width=78)
   Index Cond: (change = 42)
(2 rows)

But this same table suddenly becomes unwilling to use an index scan if
the target value is the result of the currval() function:

# explain select * from changes where change = currval('changes_change_seq');
                        QUERY PLAN
----------------------------------------------------------
 Seq Scan on changes  (cost=0.00..323.21 rows=1 width=78)
   Filter: (change = currval('changes_change_seq'::text))
(2 rows)

Explicitly casting the result of currval() to an integer (of any size)
does not seem improve the situation.  Is my expectation unreasonable
that the planner should consider the result of an INTEGER CAST in the
same way it considers a literal integer?

--
Brandon Craig Rhodes                         http://www.rhodesmill.org/brandon
Georgia Tech                                            brandon@oit.gatech.edu

pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: REINDEX issues
Next
From: Martin Marques
Date:
Subject: Re: key = currval('tab_key_seq') choses SEQSCAN?!