From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Neil Conway <neilc(at)samurai(dot)com>, Mario Weilguni <mario(dot)weilguni(at)icomedias(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: numeric hierarchy again (was Re: floor function in 7.3b2) |
Date: | 2002-10-04 19:07:40 |
Message-ID: | 25747.1033758460@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Yes, I realize it is during parsing. I was just wondering if making
> constants coming in from the parser NUMERIC is a performance hit?
Offhand I don't see a reason to think that coercing to NUMERIC (and then
something else) is slower than coercing to FLOAT (and then something else).
Yeah, you would come out a little behind when the final destination type
is FLOAT, but on the other hand you win a little when it's NUMERIC.
I see no reason to think this isn't a wash overall.
> I see
> in gram.y that FCONST comes in as a Float so I don't even see were we
> make it NUMERIC.
It's make_const in parse_node.c that has the first contact with the
grammar's output. Up to that point the value's just a string, really.
The grammar does *not* coerce it to float8.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Copeland | 2002-10-04 19:12:11 | Re: Threaded Sorting |
Previous Message | Bruce Momjian | 2002-10-04 19:02:35 | Re: Threaded Sorting |