Re: plans for PostgreSQL 12

2018-06-05 15:00 GMT+02:00 Andres Freund : > Hi, > > On 2018-06-05 06:32:31 +0200, Pavel Stehule wrote: > > ./configure --with-libxml --enable-tap-tests --enable-debug --with-perl > > CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer" > > > > [pavel@nemesis postgresql]$ gcc --version > > gcc (GCC) 8.1

Re: plans for PostgreSQL 12

Hi, On 2018-06-05 06:32:31 +0200, Pavel Stehule wrote: > ./configure --with-libxml --enable-tap-tests --enable-debug --with-perl > CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer" > > [pavel@nemesis postgresql]$ gcc --version > gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1) > > I executed simple scrip

Re: plans for PostgreSQL 12

2018-06-04 20:55 GMT+02:00 Andres Freund : > Hi, > > On 2018-06-04 07:35:23 +0100, Simon Riggs wrote: > > On 4 June 2018 at 06:08, Pavel Stehule wrote: > > > > > 4. optimization expression without necessity to create snapshots - > > > experiments > > > > > > @4 There are lot of not database expre

Re: plans for PostgreSQL 12

Hi, On 2018-06-04 07:35:23 +0100, Simon Riggs wrote: > On 4 June 2018 at 06:08, Pavel Stehule 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 :=

Re: plans for PostgreSQL 12

2018-06-04 21:53 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > 2018-06-04 9:59 GMT+02:00 Vik Fearing : > >> On 04/06/18 09:37, Pavel Stehule wrote: > >>> Yes, it is incorrect mark. Unfortunately - this is often workaround for > >>> wrong estimations - so I afraid, in this case, your proposed f

Re: plans for PostgreSQL 12

Pavel Stehule writes: > 2018-06-04 9:59 GMT+02:00 Vik Fearing : >> On 04/06/18 09:37, Pavel Stehule wrote: >>> Yes, it is incorrect mark. Unfortunately - this is often workaround for >>> wrong estimations - so I afraid, in this case, your proposed fix breaks >>> lot of applications. >> I would sa

Re: plans for PostgreSQL 12

2018-06-04 9:59 GMT+02:00 Vik Fearing : > On 04/06/18 09:37, Pavel Stehule wrote: > > > > > > 2018-06-04 9:24 GMT+02:00 Heikki Linnakangas > >: > > > > On 04/06/18 09:12, Pavel Stehule wrote: > > > > It requires introduction of new "safe" functions (& operators

Re: plans for PostgreSQL 12

On 04/06/18 09:37, Pavel Stehule wrote: > > > 2018-06-04 9:24 GMT+02:00 Heikki Linnakangas >: > > On 04/06/18 09:12, Pavel Stehule wrote: > > It requires introduction of new "safe" functions (& operators). > Immutable > functions are not enou

Re: plans for PostgreSQL 12

2018-06-04 9:24 GMT+02:00 Heikki Linnakangas : > On 04/06/18 09:12, Pavel Stehule wrote: > >> 2018-06-04 8:35 GMT+02:00 Simon Riggs : >> >>> >>> 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

Re: plans for PostgreSQL 12

On 04/06/18 09:12, Pavel Stehule wrote: 2018-06-04 8:35 GMT+02:00 Simon Riggs : 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,

Re: plans for PostgreSQL 12

2018-06-04 8:35 GMT+02:00 Simon Riggs : > On 4 June 2018 at 06:08, Pavel Stehule 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

Re: plans for PostgreSQL 12

On 4 June 2018 at 06:08, Pavel Stehule 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 expr