Tom Lane <tgl@sss.pgh.pa.us> writes:
> Indeed, and if I were setting out to parallelize queries in PG (which
> I am not), subplans would be the last thing I would think about. You
> could put an enormous amount of work in there and have nothing much
> to show for it, because the construct doesn't even arise in many
> queries. Even where the user wrote something that looks like a subplan,
> the planner will do its best to get rid of it by turning it into a
> join.
I guess that's because subplans do cost more than their alternative. The
idea was to provide a parallel implementation of them, so they get some
benefits, then compare better to plain join'ing.
But I can see that's an entirely wrong approach, and I'm happy to know
that and glad I asked, thanks :)
> So if you want to parallelize queries, start someplace else. The past
> discussions of this have revolved around splitting the node tree of an
> ordinary query plan into separately executable parts. Maybe a subplan
> could be one of the cut points for such an approach, but if it's the
> only one or even the main one, you're wasting your time.
Unless you arrange for the planner to have good (new) reasons to prefer
using subplans, or provide subplan based joins ?
Ok, once you've done that, maybe you're back to the main problem and
just changed its name.
Regards,
--
dim
