From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Constantin Teodorescu" <teo(at)flex(dot)ro>, "Bruce Momjian" <maillist(at)candle(dot)pha(dot)pa(dot)us>, "Hannu Krosing" <hannu(at)trust(dot)ee>, <pgsql-hackers(at)postgreSQL(dot)org>, "Thomas Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
Subject: | RE: [HACKERS] Interesting behaviour ! |
Date: | 1999-07-15 00:25:07 |
Message-ID: | 000a01bece58$7dd97600$2801007e@cadzone.tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: owner-pgsql-hackers(at)postgreSQL(dot)org
> [mailto:owner-pgsql-hackers(at)postgreSQL(dot)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(at)postgreSQL(dot)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(at)alumni(dot)caltech(dot)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(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-07-15 00:34:37 | Re: [HACKERS] header files for spi.h/trigger.h] |
Previous Message | Bruce Momjian | 1999-07-14 23:46:53 | Re: [HACKERS] header files for spi.h/trigger.h] |