Re: BUG #16966: Nested loop joining across tables with varchar -> bpchar cast always scans varchar table first

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: zebburkeconte(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16966: Nested loop joining across tables with varchar -> bpchar cast always scans varchar table first
Date: 2021-04-16 12:36:35
Message-ID: 4005578.1618576595@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> I'm seeing a performance issue when joining across two tables on columns
> that require a cast from varchar to bpchar. No matter how selective the
> condition is on the bpchar table, the outer scan will be on the table with
> the varchar column.

I don't think this is a planner problem. It can't generate the plan
you are hoping for because of index mismatch. The query's join
condition is effectively "a.varcharcol::bpchar = b.bpcharcol", and
the construct "a.varcharcol::bpchar" doesn't match your index on
a.varcharcol, so it can't use an inner indexscan on that side of
the equality.

Possibly you could work around this by providing an expression index on
"a.varcharcol::bpchar". But TBH my recommendation would be to nuke the
bpchar columns from orbit. They're almost never the semantics you want,
especially not if you're sometimes comparing them to non-bpchar
columns.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Zeb Burke-Conte 2021-04-16 16:16:43 Re: BUG #16966: Nested loop joining across tables with varchar -> bpchar cast always scans varchar table first
Previous Message Bruce Momjian 2021-04-15 21:38:50 Re: BUG #16965: Select query fails with ERROR: XX000: could not find pathkey item to sort