Thread: cache lookup failed for statistics object 123

cache lookup failed for statistics object 123

From
Justin Pryzby
Date:
Per sqlsmith.

postgres=# SELECT pg_get_statisticsobjdef_expressions(123);
ERROR:  cache lookup failed for statistics object 123
postgres=# \errverbose 
ERROR:  XX000: cache lookup failed for statistics object 123
LOCATION:  pg_get_statisticsobjdef_expressions, ruleutils.c:1762

The expectation is that sql callable functions should return null rather than
hitting elog().

In the 003 patch, I wonder if this part should be updated, too:

| ... which can greatly improve query plans that use the expression index.

It can improve queries even that don't use the index, right ?
Say, if a query has f(x) = 11, and the MCV list for the expression shows that
50% of the table has f(x)=11, then the query might decide to *not* use an index
scan.

-- 
Justin

Attachment

Re: cache lookup failed for statistics object 123

From
Tomas Vondra
Date:
Hi,

On 5/5/21 11:09 PM, Justin Pryzby wrote:
> Per sqlsmith.
> 
> postgres=# SELECT pg_get_statisticsobjdef_expressions(123);
> ERROR:  cache lookup failed for statistics object 123
> postgres=# \errverbose
> ERROR:  XX000: cache lookup failed for statistics object 123
> LOCATION:  pg_get_statisticsobjdef_expressions, ruleutils.c:1762
> 
> The expectation is that sql callable functions should return null rather than
> hitting elog().
> 

Right, thanks for noticing this.

> In the 003 patch, I wonder if this part should be updated, too:
> 
> | ... which can greatly improve query plans that use the expression index.
> 
> It can improve queries even that don't use the index, right ?
 >
> Say, if a query has f(x) = 11, and the MCV list for the expression shows that
> 50% of the table has f(x)=11, then the query might decide to *not* use an index
> scan.

Yeah, it should talk about improving estimates, it's mostly unrelated to 
using indexes.

regards



Re: cache lookup failed for statistics object 123

From
Tomas Vondra
Date:
I've pushed all three patches, with some better commit messages etc.

thanks!

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company