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
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 |