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 по дате отправления: