On Wed, Mar 15, 2017 at 8:49 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: >> Of course, that supposes that 0009 can manage to postpone creating >> non-sampled child joinrels until create_partition_join_plan(), which >> it currently doesn't. > > Right. We need the child-join's RelOptInfos to estimate sizes, so that > we could sample the largest ones. So postponing it looks difficult.
You have a point. >> In fact, unless I'm missing something, 0009 >> hasn't been even slightly adapted to take advantage of the >> infrastructure in 0001; it doesn't seem to reset the path_cxt or >> anything. That seems like a fairly major omission. > > The path_cxt reset introduced by 0001 recycles memory used by all the > paths, including paths created for the children. But that happens only > after all the planning has completed. I thought that's what we > discussed to be done. We could create a separate path context for > every top-level child-join. I don't think we need to create a new context for each top-level child-join, but I think we should create a context to be used across all top-level child-joins and then reset it after planning each one. I thought the whole point here was that NOT doing that caused the memory usage for partitionwise join to get out of control. Am I confused? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
