Re: [HACKERS] Runtime Partition Pruning - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Runtime Partition Pruning
Date
Msg-id CA+TgmoaEofE85BbLycU5XB9sDvaXdWFOX3oO=XW4fKfx6kAR9g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] Runtime Partition Pruning  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Mon, Apr 16, 2018 at 10:46 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> I did go and start working on a patch to test how possible this would
> be and came up with the attached. I've left a stray
> MemoryContextStatsDetail call in there which does indicate that
> something is not being freed. I'm just not sure what it is yet.
>
> The patch does happen to improve performance slightly, but that is
> most likely due to the caching of the ExprStates rather than the
> change of memory management. It's not really possible to do that with
> the reset unless we stored the executor's memory context in
> PartitionPruneContext and did a context switch back inside
> partkey_datum_from_expr before calling ExecInitExpr.

10% is more than a "slight" improvement, I'd say!  It's certainly got
to be worth avoiding the repeated calls to ExecInitExpr, whatever we
do about the memory contexts.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: pruning disabled for array, enum, record, range type partition keys
Next
From: Robert Haas
Date:
Subject: Re: pgindent run soon?