Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
От | Hannu Krosing |
---|---|
Тема | Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan |
Дата | |
Msg-id | 39A14CC2.7F932537@tm.ee обсуждение исходный текст |
Ответ на | Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan (Tiago Antão <tra@fct.unl.pt>) |
Список | 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 по дате отправления: