On Fri, Apr 29, 2022 at 12:53 AM Robert Haas wrote:
> Gather doesn't require a parallel aware subpath, just a parallel-safe
> subpath. In a case like this, the parallel seq scan will divide the
> rows from the underlying relation across the three processes executing
> it. Each process will pass t
On Thu, Apr 28, 2022 at 9:53 AM Robert Haas wrote:
> On Fri, Apr 22, 2022 at 11:55 AM David G. Johnston
> wrote:
> > On Wed, Apr 20, 2022 at 11:38 PM bu...@sohu.com wrote:
> >>
> >> > > for now fuction cost_subqueryscan always using *total* rows even
> parallel
> >> > > path. like this:
> >> >
On Fri, Apr 22, 2022 at 11:55 AM David G. Johnston
wrote:
> On Wed, Apr 20, 2022 at 11:38 PM bu...@sohu.com wrote:
>>
>> > > for now fuction cost_subqueryscan always using *total* rows even parallel
>> > > path. like this:
>> > >
>> > > Gather (rows=3)
>> > > Workers Planned: 2
>> > > ->
On Wed, Apr 20, 2022 at 11:38 PM bu...@sohu.com wrote:
> > > for now fuction cost_subqueryscan always using *total* rows even
> parallel
> > > path. like this:
> > >
> > > Gather (rows=3)
> > > Workers Planned: 2
> > > -> Subquery Scan (rows=3) -- *total* rows, should be equal
> sub
On Thu, Apr 21, 2022 at 2:38 AM bu...@sohu.com wrote:
> > Suppose parallelism is not in use and that param_info is NULL. Then,
> > is path->subpath->rows guaranteed to be equal to baserel->rows? If
> > yes, then we don't need to a three-part if statement as you propose
> > here and can just change
> > for now fuction cost_subqueryscan always using *total* rows even parallel
> > path. like this:
> >
> > Gather (rows=3)
> > Workers Planned: 2
> > -> Subquery Scan (rows=3) -- *total* rows, should be equal subpath
> > -> Parallel Seq Scan (rows=1)
>
> OK, that's bad
On Wed, Apr 20, 2022 at 10:01 AM bu...@sohu.com wrote:
> for now fuction cost_subqueryscan always using *total* rows even parallel
> path. like this:
>
> Gather (rows=3)
> Workers Planned: 2
> -> Subquery Scan (rows=3) -- *total* rows, should be equal subpath
> -> Parallel S
> Sure, but that doesn't make the patch correct. The patch proposes
> that, when parallelism in use, a subquery scan will produce fewer rows
> than when parallelism is not in use, and that's 100% false. Compare
> this with the case of a parallel sequential scan. If a table contains
> 1000 rows, and
On Fri, Apr 15, 2022 at 6:06 AM bu...@sohu.com wrote:
> > Generally it should be. But there's no subquery scan visible here.
> I wrote a patch for distinct/union and aggregate support last year(I want
> restart it again).
> https://www.postgresql.org/message-id/2021091517250848215321%40sohu.com
>
> Generally it should be. But there's no subquery scan visible here.
I wrote a patch for distinct/union and aggregate support last year(I want
restart it again).
https://www.postgresql.org/message-id/2021091517250848215321%40sohu.com
If not apply this patch, some parallel paths will naver be sele
10 matches
Mail list logo
