On 2021-02-23, Tom Lane wrote:
> Hmm ... did you remember to set the oprcanhash property on the equality
> operator?
Aaah! That was it, I had totally missed the HASHES and MERGES options to
CREATE OPERATOR. It works perfectly now that I set those.
Do those options make sense for other operators b
On 2021-02-23, Tom Lane wrote:
> Have you tried "enable_seqscan = off" (and maybe also disable merge
> and hash joins) to see if you can force choice of that plan?
No luck. It uses the index now, but seemingly only to loop over it. The
integer version uses a HashAggregate, I must have missed some
(forgot to cc the list, sorry for the duplicate, Tom!)
On 2021-02-23, Tom Lane wrote:
> Ayo writes:
> > I have a database where I converted an integer primary key column to a
> > custom base type that pretty much amounts to a wrapper around an
> > integer, and now some que
Hi,
The short version:
I have a database where I converted an integer primary key column to a
custom base type that pretty much amounts to a wrapper around an
integer, and now some queries are resulting in much slower query plans.
Does Postgres have special optimizations for integers that are not
