Re: plans for PostgreSQL 12

From: Andres Freund <andres(at)anarazel(dot)de>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plans for PostgreSQL 12
Date: 2018-06-04 18:55:28
Message-ID: 20180604185528.br3cimsxq3ndvo3b@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-06-04 07:35:23 +0100, Simon Riggs wrote:
> On 4 June 2018 at 06:08, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-06-04 19:20:43 Re: New committers announced at PGCon 2018
Previous Message Andres Freund 2018-06-04 18:52:05 Re: Spilling hashed SetOps and aggregates to disk