Re: [HACKERS] Re: type coersion (was OR clause status)
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Re: type coersion (was OR clause status) |
Дата | |
Msg-id | 35D2F879.30817CCF@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: type coersion (was OR clause status) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: type coersion (was OR clause status)
|
Список | 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? - Tom The example is from the regression test database with an extra btree index built on the tenk1 table... regression=> \d tenk1 Table = tenk1 +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | unique1 | int4 | 4 | | unique2 | int4 | 4 | | two | int4 | 4 | | four | int4 | 4 | | ten | int4 | 4 | | twenty | int4 | 4 | | hundred | int4 | 4 | | thousand | int4 | 4 | | twothousand | int4 | 4 | | fivethous | int4 | 4 | | tenthous | int4 | 4 | | odd | int4 | 4 | | even | int4 | 4 | | stringu1 | name | 32 | | stringu2 | name | 32 | | string4 | name | 32 | +----------------------------------+----------------------------------+-------+ Indices: tenk1_hundred tenk1_oid tenk1_unique1 tenk1_unique2 regression=>
В списке pgsql-hackers по дате отправления: