From: | Juan Pereira <juankarlos(dot)openggd(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PostgreSQL versus MySQL for GPS Data |
Date: | 2009-03-17 14:25:57 |
Message-ID: | 5339c9a90903170725o15b46f19u6dab070b0f50ac21@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-general |
Craig Ringer wrote:
>> You're almost always better off using a single table with a composite
>> primary key like (truckid, datapointid) or whatever. If you'll be doing
>> lots of queries that focus on individual vehicles and expect performance
>> issues then you could partition the table by truckid, so you actually do
>> land up with one table per truck, but transparently accessible via table
>> inheritance so you can still query them all together.
Quite interesting!
The main reason why we thought using a table per truck was because
concurrent load: if there are 100 trucks trying to write in the same table,
maybe the performance is worse than having 100 tables, due to the fact that
the table is blocked for other queries while the writing process is running,
isn't it?
>> My main reasons are that in a proper transactional environment (ie
>> you're not using scary MyISAM tables) Pg is *much* better about handling
>> concurrent load, particularly concurrent activity by readers and writers.
>> 2009/3/17 Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Quite interesting again.
Thank you for your answers
Juan Karlos
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-03-17 14:30:23 | Re: PostgreSQL versus MySQL for GPS Data |
Previous Message | Harald Armin Massa | 2009-03-17 14:00:52 | Re: PostgreSQL versus MySQL for GPS Data |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-03-17 14:30:23 | Re: PostgreSQL versus MySQL for GPS Data |
Previous Message | Marco Colombo | 2009-03-17 14:10:53 | Re: Maximum transaction rate |