Re: Expression indexes and casts

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Expression indexes and casts
Date: 2004-03-09 16:57:58
Message-ID: 20040309085426.C611@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 9 Mar 2004, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> writes:
> > I haven't done any looking around yet (about to head off to work), but it
> > looks like in the case where the system decides to cast a to text in order
> > to get a working equality, the index isn't used, whereas in the case where
> > I explicitly cast it, it can.
>
> I think the problem is that explicit and implicit casts are marked
> differently in the cast parse node, causing equal() to consider the two
> expressions different.
>
> There is currently a hack involving a "don't care" setting for this
> field, but it doesn't help you. I wonder if it would be better to make
> equal() explicitly ignore the cast-type field. It seems like that could
> break other things though :-(.
>
> A narrower patch would be to change the cast type field to don't-care in
> the copy of the parse tree that is made for planner user.
>
> [ thinks some more... ] On the other hand, there are cases where
> explicit and implicit casting are actually semantically different (think
> varchar() and char() length constraints). Maybe the don't-care business
> is itself a bug, and you're just stuck.

Is it possible to make an index on the implicitly cast version (or what
would that take - I'm not sure how to syntactically note that in any
case)? I don't really care about the explicit cast case actually.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steve Wolfe 2004-03-09 17:14:12 Re: Question on Opteron performance
Previous Message Richard Huxton 2004-03-09 16:53:26 Re: a group of superuser