On Fri, 1 Jan 2021 at 14:30, David Fetter <da...@fetter.org> wrote: > On Sun, Dec 01, 2019 at 11:34:16AM +0900, Michael Paquier wrote: > > Okay, still nothing has happened after two months. Once this is > > solved a new patch submission could be done. For now I have marked > > the entry as returned with feedback. > > I dusted off the last version of the patch without implementing the > suggestions in this thread between here and there. > > I think this is a capability worth having, as I was surprised when it > turned out that it didn't exist when I was looking to make an > improvement to pg_dump. My idea, which I'll get back to when this is > in, was to use special knowledge of heap AM tables to make it possible > to parallelize dumps of large tables by working separately on each > underlying file, of which there could be quite a few for a large one. > > Will try to understand the suggestions upthread better and implement > same. >
Hi David, Thanks for updating the patch. I'd be very happy if this got picked up again, and I'd certainly follow along and do some review. + splan->tidrangequals = + fix_scan_list(root, splan->tidrangequals, + rtoffset, 1); /* v9_tid XXX Not sure this is right */ I'm pretty sure the parameter num_exec = 1 is fine; it seems to only affect correlated subselects, which shouldn't really make their way into the tidrangequals expressions. It's more or less the same situation as tidquals for TidPath, anyway. We could put a little comment: /* correlated subselects shouldn't get into tidquals/tidrangequals */ or something to that effect. Edmund
