Re: [HACKERS] Runtime Partition Pruning
Andy Fan <zhihui.fan1213@gmail.com>
From: Andy Fan <zhihui.fan1213@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Beena Emerson <memissemerson@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, amul sul <sulamul@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Dilip Kumar <dilipbalaut@gmail.com>, Amit Langote <amitlangote09@gmail.com>, David Rowley <dgrowleyml@gmail.com>
Date: 2020-10-12T12:22:45Z
Lists: pgsql-hackers
On Mon, Oct 12, 2020 at 5:48 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > On Mon, Oct 12, 2020 at 7:59 AM Andy Fan <zhihui.fan1213@gmail.com> wrote: > > > > > Sorry for the late reply! Suppose we have partition defined like this: > > p > > - p1 > > - p2 > > > > When you talk about "the statistics from the partitioned table", do you > > mean the statistics from p or p1/p2? I just confirmed there is no > statistics > > for p (at least pg_class.reltuples = -1), so I think you are talking > about > > p1/p2. > > I am talking about p when I say statistics from the partitioned table. > I see that pg_statistic row from p is well populated. > pg_class.reltuples = -1 indicates that the heap doesn't have any rows. > set_rel_size() sets the number of rows in the partitioned table based > on the rows in individual unpruned partitions. > > Glad to know that, Thanks for this info! > > > > Here we are talking about partkey = $1 or partkey = RunTimeValue. > > so even the value can hit 1 partition only, but since we don't know > > the exact value, so we treat all the partition equally. so looks > > nothing wrong with partition level estimation. However when we cost > > the Append path, we need know just one of them can be hit, then > > we need do something there. Both AppendPath->rows/total_cost > > should be adjusted (That doesn't happen now). > > I think in this case we can safely assume that only one partition will > remain so normalize costs considering that only one partition will > survive. > Exactly. What I am trying to do is fix this at create_append_path, do you have different suggestions? about the pkey > $1 case, I think even if we use the statistics from partition level, it would be hard-code as well since we don't know what value $1 is. I have gone through the main part of the RunTime partition prune, hope I can update a runnable patch soon. The main idea is fix the rows/ costs at create_append_path stage. So any suggestion in a different direction will be very useful. -- Best Regards Andy Fan
Commits
-
Initialize ExprStates once in run-time partition pruning
- 1957f8dabf8d 11.0 landed
-
Add bms_prev_member function
- 5c0675215e15 11.0 landed
-
Support partition pruning at execution time
- 499be013de65 11.0 landed
-
Document partprune.c a little better
- 971d7ddbe19a 11.0 landed
-
Fix crash in pg_replication_slot_advance
- 6f1d723b6359 11.0 cited
-
Add parallel-aware hash joins.
- 1804284042e6 11.0 cited
-
Fix typo.
- 487a0c1518af 11.0 cited
-
Allow --with-bonjour to work with non-macOS implementations of Bonjour.
- 9b9cb3c4534d 11.0 cited
-
Mention need for --no-inc-recursive in rsync command
- 2c74e6c1dcc5 11.0 cited