Re: [HACKERS] Re: type coersion (was OR clause status)

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Re: type coersion (was OR clause status)
Дата
Msg-id 199808131505.LAA17807@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: type coersion (was OR clause status)  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Table permissions problem
Следующее
От: jwieck@debis.com (Jan Wieck)
Дата:
Сообщение: Re: [HACKERS] tuple return from function