On Fri, Mar 22, 2019 at 9:07 PM, Tom Lane wrote: > BTW, it strikes me that we could take advantage of the fact that baserels > must all appear before otherrels in the rel array, by having loops over > that array stop early if they're only interested in baserels. We could > either save the index of the last baserel, or just extend the loop logic > to fall out upon hitting an otherrel. > Seems like this'd save some cycles when there are lots of partitions, > although perhaps loops like that would be fast enough to not matter.
Actually, this speeds up planning time little when scanning a lot of otherrels like selecting thousands of partitions. I tested below. * rt with 8192 partitions * execute "select * from rt;" for 60 seconds. [results] HEAD: 4.19 TPS (4.06, 4.34, 4.17) (v34 patches) + (looping over only baserels): 4.26 TPS (4.31, 4.28, 4.19) Attached is the diff I used for this test. -- Yoshikazu Imai
looping-over-last-baserel-idx.diff
Description: looping-over-last-baserel-idx.diff
