Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jean Landercy - BEEODIVERSITY <jean(dot)landercy(at)beeodiversity(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Sudden database error with COUNT(*) making Query Planner crashes: variable not found in subplan target list
Date: 2022-06-07 20:49:05
Message-ID: CAApHDvqFu4S0f4TesWZU8ArjFhu0j4gZZVBEQCNO5rfhzYQ1Sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 8 Jun 2022 at 08:31, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> So it does appear that the location index is being chosen, at least
> with the data that I inserted. Those gist indexes are costing quite a
> bit cheaper than the cheapest btree index.

This seems just to be because the gist indexes are smaller, which is
likely due to me having inserted NULL values into them.

postgres=# select pg_relation_size('logistic_site_key_key');
pg_relation_size
------------------
16384
(1 row)

postgres=# select pg_relation_size('logistic_site_location_54ae0166_id');
pg_relation_size
------------------
8192
(1 row)

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2022-06-07 20:51:50 Re: Collation version tracking for macOS
Previous Message Peter Geoghegan 2022-06-07 20:41:33 Re: Collation version tracking for macOS