Re: [PATCH] Avoid collation lookup for "char" statistics - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Avoid collation lookup for "char" statistics
Date
Msg-id 1444961.1782661140@sss.pgh.pa.us
Whole thread
In response to Re: [PATCH] Avoid collation lookup for "char" statistics  (Feng Wu <wufengwufengwufeng@gmail.com>)
List pgsql-hackers
Feng Wu <wufengwufengwufeng@gmail.com> writes:
> Thanks for looking at it.  I should have included the exact reproducer in
> the first email.
> The failure needs histogram statistics on a "char" column, so simple
> catalog joins such as the pg_type example do not necessarily reach the
> problematic path.

Ah, now I understand.  The failing code is only reached if we have
a histogram on a "char" column.  For almost all the catalogs with
"char" columns, there is no histogram because there are very few
distinct values and so the MCV list accounts for all of them.
Even where there is a histogram, it'd be unlikely for someone to
issue a query that would hit this code, so the lack of prior
reports isn't as surprising as I thought.

Your example could be simplified though.  The failure is within
scalarineqsel, so we don't need a join at all, just an inequality
qual:

regression=# explain verbose select * from char_stats_1 where c < 'c';
ERROR:  cache lookup failed for collation 0

I agree that just skipping the collation correction is the right
fix.  We could make the patch a bit shorter by simply returning
out of the CHAROID case in the preceding switch.  Will see to it.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Feng Wu
Date:
Subject: Re: [PATCH] Avoid collation lookup for "char" statistics
Next
From: Rui Zhao
Date:
Subject: Re: [PATCH] Add pg_get_table_ddl() to reconstruct CREATE TABLE statements