Re: [HACKERS] Re: type coersion (was OR clause status) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] Re: type coersion (was OR clause status)
Date
Msg-id 199808131505.LAA17807@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] Re: type coersion (was OR clause status)  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
List pgsql-hackers
> > > The first thing I want to try is to substitute the operator for
> > > types which are known to be binary-compatible and do not have their
> > > own index defined.
>
> Got a start on it :)
>
> regression=> explain select * from tenk1 where oid = 3000;
> NOTICE:  QUERY PLAN:
>
> Index Scan using tenk1_oid on tenk1  (cost=2.05 size=1 width=148)
>
> EXPLAIN
>
> So far, I've just done the right-hand form (the one with the constant on
> the rhs of the expression). The left-hand form should be easy now.
>
> So, just curious: if we stop here, and only match up binary-compatible
> built-in types with available indices, then what v6.3.2 features/good
> behaviors are still missing?

Did you put it in the optimizer?

I think binary compatable types converted is going to be the easiest
thing to do for index use.  Not sure how you could try and break it.
How about character string comparisons using indexes?

> |    32 |
> +----------------------------------+----------------------------------+-------+
> Indices:  tenk1_hundred
>           tenk1_oid
>           tenk1_unique1
>           tenk1_unique2
  ^^^^^^^^^^^^^^^^^^^^^^^^^

How about that new display?


--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Table permissions problem
Next
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] tuple return from function