Skip site navigation (1) Skip section navigation (2)

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

From: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
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 05:24:59
Message-ID: 47C7972B.1020202@mark.mielke.cc (view raw or flat)
Thread:
Lists: pgsql-hackers
James Mansion wrote:
> 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. 

Instruction level parallelism allows for multiple hex values to be 
processed in parallel, whereas a loop relies on branch prediction and 
speculative load and store? :-)

The liberal version is difficult to unroll. The strict version is easy 
to unroll.

> 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.

I think so too.

Cheers,
mark

-- 
Mark Mielke <mark(at)mielke(dot)cc>


In response to

pgsql-hackers by date

Next:From: Tom DunstanDate: 2008-02-29 05:40:39
Subject: Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
Previous:From: Tom LaneDate: 2008-02-29 05:05:45
Subject: Re: Batch update of indexes on data loading

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group