Re: plans for PostgreSQL 12
От | Andres Freund |
---|---|
Тема | Re: plans for PostgreSQL 12 |
Дата | |
Msg-id | 20180604185528.br3cimsxq3ndvo3b@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: plans for PostgreSQL 12 (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: plans for PostgreSQL 12
|
Список | pgsql-hackers |
Hi, On 2018-06-04 07:35:23 +0100, Simon Riggs wrote: > On 4 June 2018 at 06:08, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > 4. optimization expression without necessity to create snapshots - > > experiments > > > > @4 There are lot of not database expressions in PLpgSQL - like var1 := var1 > > + var2 or var1 := var1 + konst. Own calculation needs about 1% of time of > > total expression evaluation time. Almost all time get preparing plan cache, > > preparing snapshot, .. For this case, when no database object is used, we > > don't need use this infrastructure. I would to measure performance impact, > > and testing if these optimizations are interesting or not. Can you show your testcase and the corresponding profile? It seems like this should be solvable without adding a new "snapshotless, really immutable" class. > Sounds good. I think this would need to be restricted by operator and > datatype, since in general you won't know if the datatype functions > need a snapshot or not. Immutable functions for the operators ought to > do it, but I think that might not be enough. It'd indeed not be enough. E.g. enum_lt et al are immutable but access the catalog. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: