From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: slow queries over information schema.tables
Date: Wed, 05 Dec 2018 13:22:23 -0500
Message-ID: <8210.1544034143@sss.pgh.pa.us> (raw)
In-Reply-To: <20181205175657.s7mt6as356kwvrji@alap3.anarazel.de>
References: <CAFj8pRBUCX4LZ2rA2BbEkdD6NN59mgx+BLo1gO08Wod4RLtcTg@mail.gmail.com>
<5978.1544030694@sss.pgh.pa.us>
<20181205175657.s7mt6as356kwvrji@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2018-12-05 12:24:54 -0500, Tom Lane wrote:
>> There are two different issues in that. One is that the domain might
>> have constraints (though in reality it does not), so the planner can't
>> throw away the CoerceToDomain node, and thus can't match the expression
>> to the index. Even if we did throw away the CoerceToDomain, it still
>> would not work because the domain is declared to be over varchar, and
>> so there's a cast-to-varchar underneath the CoerceToDomain.
> Couldn't we make expression simplification replace CoerceToDomain with a
> RelabelType if the constraint is simple enough? That's not entirely
> trivial because we'd have to look into the typecache to get the
> constraints, but that doesn't sound too bad.
Not following what you have in mind here? My 0002 throws away the
CoerceToDomain if there are *no* constraints, but I can't see any
situation in which we'd likely be able to ignore a constraint,
simple or not.
>> 0003 essentially converts "namecol::text texteq textvalue" into
>> "namecol nameeqtext textvalue", relying on the new equality
>> operator introduced by 0001.
> Ugh, that's indeed a bit kludgy. It'd be nice to have an approach that's
> usable outside of one odd builtin type. I was wondering for a bit
> whether we could have logic to move the cast to the other side of an
> operator, but I don't see how we could make that generally safe.
Yeah. It seems like it could be a special case of a more general
expression transform facility, but we have no such facility now.
On the other hand, all of match_special_index_operator is an ugly
single-purpose kluge already, so I'm not feeling that awful about
throwing another special case into it. Someday it would be nice
to replace that code with something more general and extensible,
but today is not that day as far as I'm concerned.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, pavel.stehule@gmail.com
Subject: Re: slow queries over information schema.tables
In-Reply-To: <8210.1544034143@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox