Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Date
Msg-id 39A14CC2.7F932537@tm.ee
Whole thread Raw
In response to Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan  (Tiago Antão <tra@fct.unl.pt>)
List pgsql-hackers
Tiago Antão wrote:
> 
> Hi!
> 
> On Mon, 21 Aug 2000, Hannu Krosing wrote:
> 
> > And predictability is GOOD ;)
> >
> > I would even suggest that PG would warn about or even refuse to run
> > queries
> > that have both nextval and curval of the same sequence inside them
> > (and pre-evaluate nextval) as only that case has _any_ predictability.
> 
>  Isn't the problem more general than just nextval? Any user defined
> function with side-effects would be a problematic one... plus a user
> defined function might not be constant:
> select ... from ... where x in (select side_effects(x) ...)
>   On correlated subqueries there is no guarantee of being constant.
> 
>   In Prolog, which is a declarative language with some similarities to
> relational algebra the ideia is: "if you use predicates with side effects,
> then you're on your own".

And you are probably even worse off in SQL where the query plan changes as 
tables are filled up, so you can't even find out what will happen by testing.

with currval marked as constant I would at least know about what currval 
will return.

---------------
Hannu


pgsql-hackers by date:

Previous
From: Adam Haberlach
Date:
Subject: Re: Bug tracking (was Re: +/- Inf for float8's)
Next
From: Hannu Krosing
Date:
Subject: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan