Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x - Mailing list pgsql-hackers

From James Mansion
Subject Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
Date
Msg-id 47C74CC5.1090200@mansionfamily.plus.com
Whole thread Raw
In response to Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x  (Mark Mielke <mark@mark.mielke.cc>)
Responses Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x  (Mark Mielke <mark@mark.mielke.cc>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
Next
From: Sam Mason
Date:
Subject: Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x