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
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 |