Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x

From: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
To: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
Cc: Kenneth Marshall <ktm(at)rice(dot)edu>, Zeugswetter Andreas ADI SD <Andreas(dot)Zeugswetter(at)s-itsolutions(dot)at>, Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
Date: 2008-02-29 00:07:33
Message-ID: 47C74CC5.1090200@mansionfamily.plus.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Mason 2008-02-29 00:09:45 Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
Previous Message Mark Mielke 2008-02-28 23:45:18 Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x