Mark Mielke wrote:
I recall there being a measurable performance difference between the
most liberal parser, and the most optimized parser, back when I wrote
one for PostgreSQL. I don't know how good the one in use for
PostgreSQL 8.3 is. As to whether the cost is noticeable to people or
not - that depends on what they are doing. The problem is that a UUID
is pretty big, and parsing it liberally means a loop.
It just seems odd - I would have thought one would use re2c or ragel to
generate something and the performance would essentially be O[n] on the
input length in characters - using either a collection of allowed forms
or an engine that normalises case and discards the '-' characters
between any hex pairs. So yes these would have a control loop. Is that
so bad?
Either way its hard to imagine how parsing a string of this length could
create a measurable performance issue compared to what will happen with
the value post parse.
James
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
