On Mon, Jul 22, 2024 at 5:55 PM Richard Guo wrote:
> Otherwise I think the v3 patch looks good to me.
>
> Attached is an updated version of this patch with cosmetic changes and
> comment updates. It also squishes the two patches together into one.
> I'm planning to push it soon, barring any objec
On Mon, Jul 22, 2024 at 4:47 PM Anthonin Bonnefoy
wrote:
> On Wed, Jul 17, 2024 at 3:59 AM Richard Guo wrote:
> > I can reproduce this problem with the query below.
> >
> > explain (costs on) select * from tenk1 order by twenty;
> >QUERY PLAN
> > --
On Wed, Jul 17, 2024 at 3:59 AM Richard Guo wrote:
>
> I can reproduce this problem with the query below.
>
> explain (costs on) select * from tenk1 order by twenty;
>QUERY PLAN
> -
I can reproduce this problem with the query below.
explain (costs on) select * from tenk1 order by twenty;
QUERY PLAN
-
Gather Merge (cost=772.11..830.93 rows=5882 width=244)
Wor
Hi Rafia,
Thanks for reviewing.
On Wed, Jul 10, 2024 at 4:54 PM Rafia Sabih wrote:
> But I don't quite understood the purpose of this,
> + total_groups = input_rel->rows;
> +
> + /*
> + * If the number of rows is unknown, fallback to gather rows
> + * estimation
> + */
> + if (total_groups == 0)
Hello Anthonin,
I spent some time on this problem and your proposed solution.
As I understand it, this is the correction for the row count when the
number of parallel workers < 4.
Once the number of workers is 4 or more, the output from
parallel_divisor is the same as the number of parallel worker
Hi,
While experimenting on an explain option to display all plan candidates
(very rough prototype here [1]), I've noticed some discrepancies in some
generated plans.
EXPLAIN (ALL_CANDIDATES) SELECT * FROM pgbench_accounts order by aid;
Plan 1
-> Gather Merge (cost=11108.32..22505.38 rows=1
