Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan
От | Tom Lane |
---|---|
Тема | Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan |
Дата | |
Msg-id | 26387.967005973@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan (Hannu Krosing <hannu@tm.ee>) |
Список | pgsql-hackers |
Hannu Krosing <hannu@tm.ee> writes: > Could we add an additional function with strictly defined behaviour of > returning the value of a sequence at the beginning of current query, perhaps > called ccurval() Not unless you want the system to run around and read the current value of *every* sequence object at the start of *every* transaction, as insurance against the possibility that some bit of code might ask for the value of ccurval('foo') at some point in the transaction. This state-saving could doubtless be optimized away to some extent, but quite frankly I don't feel a strong need to work on it. You haven't yet presented any compelling reason why we should care deeply about the performance of WHERE bar = currval('foo') --- how many people want to do that? Even more to the point, why is this so important that we should care about making it fast with absolutely no help from the user? I have a hard time accepting an "I won't use plpgsql" argument. There are many more pressing performance problems on my to-do list, most of them with no such easy workaround. regards, tom lane
В списке pgsql-hackers по дате отправления: