From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: On disable_cost |
Date: | 2024-06-12 18:33:31 |
Message-ID: | CA+TgmoZU0SLCeo80yU3KBUNMQAbr3Vs0aMvsMr97pB-JqO08hw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 12, 2024 at 2:11 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> <can't resist trying if I see overhead>
>
> In an extreme case i can see a tiny bit of overhead, but not enough to be
> worth worrying about. Mostly because we're so profligate in doing
> bms_overlap() that cost comparisons don't end up mattering as much - I seem to
> recall that being different in the not distant past though.
There are very few things I love more than when you can't resist
trying to break my patches and yet fail to find a problem. Granted the
latter part only happens once a century or so, but I'll take it.
> Aside: I'm somewhat confused by add_paths_to_joinrel()'s handling of
> mergejoins_allowed. If mergejoins are disabled we end up reaching
> match_unsorted_outer() in more cases than with mergejoins enabled. E.g. we
> only set mergejoin_enabled for right joins inside select_mergejoin_clauses(),
> but we don't call select_mergejoin_clauses() if !enable_mergejoin and jointype
> != FULL. I, what?
I agree this logic is extremely confusing, but "we only set
mergejoin_enabled for right joins inside select_mergejoin_clauses()"
doesn't seem to be true. It starts out true, and always stays true
except for right, right-anti, and full joins, where
select_mergejoin_clauses() can set it to false. Since the call to
match_unsorted_outer() is gated by mergejoin_enabled, you might think
that we'd skip considering nested loops on the strength of not being
able to do a merge join, but comment "2." in add_paths_to_joinrel
explains that the join types for which mergejoin_enabled can end up
false aren't supported by nested loops anyway. Still, this logic is
really tortured.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-06-12 18:45:35 | Re: Improve the granularity of PQsocketPoll's timeout parameter? |
Previous Message | Tom Lane | 2024-06-12 18:25:11 | Re: Improve the granularity of PQsocketPoll's timeout parameter? |