Re: cache lookup failed for statistics object 123

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: cache lookup failed for statistics object 123
Date: 2021-05-06 20:25:06
Message-ID: 8c78067f-9562-6e78-bf56-b29116e81faf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-05-06 20:35:56 Re: [BUG]"FailedAssertion" reported in lazy_scan_heap() when running logical replication
Previous Message Andreas Seltenreich 2021-05-06 20:24:21 Re: Multiple hosts in connection string failed to failover in non-hot standby mode