Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Tiago Antão <tra(at)fct(dot)unl(dot)pt>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
Date: 2000-08-21 15:37:38
Message-ID: 39A14CC2.7F932537@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-08-21 15:40:05 Re: Row Level Locking Problem
Previous Message Hannu Krosing 2000-08-21 15:32:24 Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan