Re: Tagging rows into collections? - Mailing list pgsql-sql
From | Richard Huxton |
---|---|
Subject | Re: Tagging rows into collections? |
Date | |
Msg-id | [email protected] Whole thread Raw |
In response to | Re: Tagging rows into collections? (Tom Lane <[email protected]>) |
List | pgsql-sql |
On Wednesday 19 Jun 2002 10:19 pm, Tom Lane wrote: > Steve Wampler <[email protected]> writes: > > An event has: timestamp,event_name,list_of_attributes > > The list_of_attributes are simple (string) name,value pairs. > > > > However, although selection performance isn't a priority, the > > ability to reconstruct the events from the database is needed > > and the above simple table doesn't provide enough information > > to do so. (The resolution on the timestamp field isn't > > enough to distinquish separate events that have the same name.) > > What PG version are you using? In 7.2 the default timestamp resolution > is microseconds, rather than seconds. That might be enough to fix your > problem. Still doesn't *guarantee* uniqueness though, just makes it less likely. > If not, your two-table approach sounds reasonable. You could stick > with one table and use arrays for the name/value columns, but that > will make searches harder. How about using a sequence to generate unique numbers for you? Looks like a SERIAL type won't be much use, but a sequence can used without tying it to a field. One thing to be careful of - if you have multiple clients inserting then the numbers won't necessarily be in order. That is, client 1 might insert 10,11,12,13 and client 2 20,21,22,23 but in time-order they might be 10,11,20,12,22,23,13. This is because each client will get a batch of numbers to use (for efficiency reasons). Be aware that I'm not 100% certain on that last sentence. - Richard Huxton