On Fri, 3 Nov 2023 at 01:02, Richard Guo wrote:
> It seems that the test is still not stable on 32-bit machines even after
> 4b14e18714. I see the following plan diff on cfbot [1].
I recreated that locally this time. Seems there's still flexibility
to push or not push down the sort and the
On Thu, Nov 2, 2023 at 3:19 PM David Rowley wrote:
> I'm not yet seeing any failures in the buildfarm, so don't really want
> to push a fix for this one if there are going to be a few more
> unstable ones to fix. I may just hold off a while to see.
It seems that the test is still not stable
On Thu, Nov 02, 2023 at 08:19:35PM +1300, David Rowley wrote:
> No tests were introduced. Is this the only existing one that's
> unstable as far as you saw?
That seems to be the only one.
> I'm not yet seeing any failures in the buildfarm, so don't really want
> to push a fix for this one if
On Thu, 2 Nov 2023 at 18:39, Michael Paquier wrote:
> The CI has been telling me that the plans of the tests introduced by
> this patch are not that stable when building with 32b. See:
> diff -U3 /tmp/cirrus-ci-build/contrib/postgres_fdw/expected/postgres_fdw.out
>
On Thu, Nov 02, 2023 at 02:32:44PM +1300, David Rowley wrote:
> No takers on the additional testing so I've pushed the patch that
> increases it to 0.2.
The CI has been telling me that the plans of the tests introduced by
this patch are not that stable when building with 32b. See:
diff -U3
On Thu, Nov 2, 2023 at 02:32:44PM +1300, David Rowley wrote:
> On Tue, 31 Oct 2023 at 11:16, David Rowley wrote:
> > I'd be happy if anyone else would like to try the same experiment to
> > see if there's some other value of DEFAULT_FDW_TUPLE_COST that might
> > suit better.
>
> No takers on
On Tue, 31 Oct 2023 at 11:16, David Rowley wrote:
> I'd be happy if anyone else would like to try the same experiment to
> see if there's some other value of DEFAULT_FDW_TUPLE_COST that might
> suit better.
No takers on the additional testing so I've pushed the patch that
increases it to 0.2.
On Tue, 31 Oct 2023 at 03:01, Bruce Momjian wrote:
> I think you just go and change it. Your number is better than what we
> have, and if someone wants to suggest a better number, we can change it
> later.
I did some more experimentation on the actual costs of getting a tuple
from a foreign
On Mon, Oct 30, 2023 at 02:22:08PM +1300, David Rowley wrote:
> If I change STD_FUZZ_FACTOR to something like 1.001 then the plans
> no longer change when I do:
>
> alter server loopback options (add fdw_tuple_cost '0.01');
>
> alter server loopback options (drop fdw_tuple_cost);
>
>
>
Looks like the value goes long back to
d0d75c402217421b691050857eb3d7af82d0c770. The comment there adds
"above and beyond cpu_tuple_cost". So certainly it's expected to be
higher than cpu_tuple_cost. I have no memories of this. But looking at
the surrounding code, I think DEFAULT_FDW_STARTUP_COST
On Sun, 29 Oct 2023 at 12:45, Bruce Momjian wrote:
> Has anything been done about this issue?
Nothing has been done. I was hoping to get the attention of a few
people who have dealt more with postgres_fdw in the past.
I've attached a patch with adjusts DEFAULT_FDW_TUPLE_COST and sets it
to 0.2.
Has anything been done about this issue?
---
On Wed, Aug 3, 2022 at 02:56:12AM +1200, David Rowley wrote:
> Over on [1] I was complaining that I thought DEFAULT_FDW_TUPLE_COST,
> which is defined as 0.01 was
Over on [1] I was complaining that I thought DEFAULT_FDW_TUPLE_COST,
which is defined as 0.01 was unrealistically low.
For comparison, cpu_tuple_cost, something we probably expect to be in
a CPU cache is also 0.01. We've defined DEFAULT_PARALLEL_TUPLE_COST
to be 0.1, which is 10x cpu_tuple_cost.
13 matches
Mail list logo
