Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
От | James Mansion |
---|---|
Тема | Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x |
Дата | |
Msg-id | 47C74CC5.1090200@mansionfamily.plus.com обсуждение исходный текст |
Ответ на | Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x (Mark Mielke <mark@mark.mielke.cc>) |
Ответы |
Re: UUID data format 4x-4x-4x-4x-4x-4x-4x-4x
|
Список | 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 по дате отправления: