RE: [HACKERS] Interesting behaviour !

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема RE: [HACKERS] Interesting behaviour !
Дата
Msg-id 000a01bece58$7dd97600$2801007e@cadzone.tpf.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] Interesting behaviour !  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
> Sent: Thursday, July 15, 1999 7:48 AM
> To: Thomas Lockhart
> Cc: Constantin Teodorescu; Bruce Momjian; Hannu Krosing;
> pgsql-hackers@postgreSQL.org
> Subject: Re: [HACKERS] Interesting behaviour ! 
> 
> 
> I wrote:
> >> This might be a relatively simple bug to fix after all,
> >> but it needs more time to find exactly where things are going wrong...
> >> and I have to get some Real Work done...
> 
> Well, no, it's not simple.  After looking at the executor I can see that
> indexscan support is only prepared to deal with comparison operators
> that are in the pg_amop class associated with the index.  In other
> words, for an int2 index the indexquals have to be "int2 op int2".
> The optimizer is doing the right thing by not trying to use int24eq
> as an indexqual.
> 
> So, we're back to needing to figure out that we can reduce the int4
> constant to an int2 constant and adjust the comparison operator
> appropriately.
> 
> Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> > Don't let me stop anyone from looking at this, but fyi this is the one
> > area I didn't yet touch for the "transparent type coersion" work I did
> > for v6.4 and which is still ongoing of course. 
> >
> > istm that wherever index use is evaluated one could allow
> > pre-evaluated functions on constants, rather than just strict
> > constants as is the case now. There is a precedent for pre-evaluation
> > of elements of the query tree.
> 
> Perhaps that could be handled by the constant-subexpression-reducer
> that I want to add.  That is, "typeconversionfunction(constant)" would
> be reduced to "constant", and then the optimizer has the same case to
> deal with as it has now.
>

Each type has a typeinput(char * => type ) proc and a typeoutput(
type -> char *) proc.

For example int2in/int2out for type int2 and int4in/int4out for type int4.
Doesn't int2in(int4out()) convert int4 to int2 ?

However,typeinput proc causes elog(ERROR) in most cases if it 
couldn't convert correctly.  

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp  


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] header files for spi.h/trigger.h]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] header files for spi.h/trigger.h]