Greg Stark writes:
> On Mon, 3 Apr 2023 at 19:32, Tom Lane wrote:
>> Or we could rethink the design goal of not allowing enable_foo switches
>> to cause us to fail to make a plan. That might be unusable though.
> The only one that gives me pause is enable_seqscan. I've seen multiple
> sites tha
On Mon, 3 Apr 2023 at 19:32, Tom Lane wrote:
>
> Or we could rethink the design goal of not allowing enable_foo switches
> to cause us to fail to make a plan. That might be unusable though.
Off the top of my head I don't see why. It's not like the possible
plans are going to change on you often,
On Tue, Apr 4, 2023 at 3:38 AM Quan Zongliang wrote:
> Because someone noticed that when he set enable_hashjoin,
> enable_mergejoin and enable_nestloop to off. The statement seemed to get
> stuck (actually because it chose the NestedLoop path, which took a long
> long time to run).
> If enable_has
On 2023/4/3 19:44, Tomas Vondra wrote:
On 4/3/23 12:23, Quan Zongliang wrote:
Hi,
I found that the enable_hashjoin disables HashJoin completely.
It's in the function add_paths_to_joinrel:
if (enable_hashjoin || jointype == JOIN_FULL)
hash_inner_and_outer(root, joinrel, outerrel, innerr
David Rowley writes:
> I think there would be quite a bit of work to do before we could ever
> start to think about that. The planner does quite a bit of writing on
> the parse, e.g adding new RangeTblEntrys to the query's rtable. We'd
> either need to fix all those first or make a copy of the pa
Andres Freund writes:
> It sounds too hard compared to the gains, but another way could be to plan
> with the relevant path generation hard disabled, and plan from scratch, with
> additional scan types enabled, if we end up being unable to generate valid
> plan.
Actually, I kind of like that. It
On Tue, 4 Apr 2023 at 11:18, Andres Freund wrote:
> It sounds too hard compared to the gains, but another way could be to plan
> with the relevant path generation hard disabled, and plan from scratch, with
> additional scan types enabled, if we end up being unable to generate valid
> plan.
I thin
Hi,
On 2023-04-03 14:04:30 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 3, 2023 at 8:13 AM Tom Lane wrote:
> >> Personally, I'd get rid of disable_cost altogether if I could.
> >> I'm not in a hurry to extend its use to more places.
>
> > I agree. I've wondered if we should put
On Mon, Apr 3, 2023 at 2:04 PM Tom Lane wrote:
> Yeah. In some places it would not be too hard; for example, if we
> generated seqscan paths last instead of first for baserels, the rule
> could be "generate it if enable_seqscan is on OR if we made no other
> path for the rel". It's much messier
Robert Haas writes:
> On Mon, Apr 3, 2023 at 8:13 AM Tom Lane wrote:
>> Personally, I'd get rid of disable_cost altogether if I could.
>> I'm not in a hurry to extend its use to more places.
> I agree. I've wondered if we should put some work into that. It feels
> bad to waste CPU cycles generat
On Mon, Apr 3, 2023 at 8:13 AM Tom Lane wrote:
> Personally, I'd get rid of disable_cost altogether if I could.
> I'm not in a hurry to extend its use to more places.
I agree. I've wondered if we should put some work into that. It feels
bad to waste CPU cycles generating paths we intend to basica
Quan Zongliang writes:
> I found that the enable_hashjoin disables HashJoin completely.
Well, yeah. It's what you asked for.
> Instead, it should add a disable cost to the cost calculation of
> hashjoin.
Why? The disable-cost stuff is a crude hack that we use when
turning off a particular pl
On 4/3/23 12:23, Quan Zongliang wrote:
> Hi,
>
> I found that the enable_hashjoin disables HashJoin completely.
> It's in the function add_paths_to_joinrel:
>
> if (enable_hashjoin || jointype == JOIN_FULL)
> hash_inner_and_outer(root, joinrel, outerrel, innerrel,
> jointype,
Hi,
I found that the enable_hashjoin disables HashJoin completely.
It's in the function add_paths_to_joinrel:
if (enable_hashjoin || jointype == JOIN_FULL)
hash_inner_and_outer(root, joinrel, outerrel, innerrel,
jointype, &extra);
Instead, it should add a
14 matches
Mail list logo
