Re: [HACKERS] Runtime Partition Pruning
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Runtime Partition Pruning |
Дата | |
Msg-id | CA+TgmoaEofE85BbLycU5XB9sDvaXdWFOX3oO=XW4fKfx6kAR9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Runtime Partition Pruning (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Runtime Partition Pruning
|
Список | 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 по дате отправления: