On Thu, Nov 2, 2017 at 11:35 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Nov 2, 2017 at 8:01 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: >> That forces materialization, and I'm guessing part of Tomas's goal >> here is to prevent the need to materialize into a temp table / >> tuplestore / etc. > > I get that, but if you're running a query like "SELECT * FROM > bigtable", you don't need parallel query in the first place, because a > single backend is quite capable of sending back the rows as fast as a > client can read them. If you're running a query like "SELECT * FROM > bigtable WHERE <highly selective predicate>" then that's a good use > case for parallel query, but then materializing it isn't that bad > because the result set is a lot smaller than the original table. > > I am not disputing the idea that there are *some* cases where parallel > query is useful and materialization is still undesirable, of course.
Not seeing a code-level review of the proposed patch, I am moving it to next CF to let the discussion move on. Nobody has registered as reviewer yet. -- Michael
