RE: [HACKERS] Interesting behaviour !

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

In response to

Responses

Browse pgsql-hackers by date

  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]