Hi,
On Oct 27, 2022, 21:29 +0800, Tom Lane , wrote:
> Zhang Mingli writes:
> > How about combine ec->ec_sources and ec->derives as one list for less codes?
>
> Keeping them separate is required for the broken-EC code paths.
> Even if it weren't, I wouldn't merge them just to save a couple
> of li
Zhang Mingli writes:
> How about combine ec->ec_sources and ec->derives as one list for less codes?
Keeping them separate is required for the broken-EC code paths.
Even if it weren't, I wouldn't merge them just to save a couple
of lines of code --- I think it's useful to be able to tell which
cla
HI,
On Oct 26, 2022, 06:09 +0800, Tom Lane , wrote:
> While fooling with my longstanding outer-join variables changes
> (I am making progress on that, honest), I happened to notice that
> equivclass.c is leaving some money on the table by generating
> redundant RestrictInfo clauses. It already att
Richard Guo writes:
> On Wed, Oct 26, 2022 at 6:09 AM Tom Lane wrote:
>> The only thing that I think might be controversial here is that
>> I dropped the check for matching operator OID. To preserve that,
>> we'd have needed to use get_commutator() in the reverse-match cases,
>> which it seemed
On Wed, Oct 26, 2022 at 6:09 AM Tom Lane wrote:
> While fooling with my longstanding outer-join variables changes
> (I am making progress on that, honest), I happened to notice that
> equivclass.c is leaving some money on the table by generating
> redundant RestrictInfo clauses. It already attem
While fooling with my longstanding outer-join variables changes
(I am making progress on that, honest), I happened to notice that
equivclass.c is leaving some money on the table by generating
redundant RestrictInfo clauses. It already attempts to not generate
the same clause twice, which can save
