Re: Using Postgres to store high volume streams of sensor readings
От | Scara Maccai |
---|---|
Тема | Re: Using Postgres to store high volume streams of sensor readings |
Дата | |
Msg-id | 301912.85421.qm@web28106.mail.ukl.yahoo.com обсуждение исходный текст |
Ответ на | Using Postgres to store high volume streams of sensor readings ("Ciprian Dorin Craciun" <ciprian.craciun@gmail.com>) |
Список | pgsql-general |
> If you watch the speed, you'll see that the insert > speed is the > same, but the scan speed is worse (from 32k to 200). As I said, I don't know a lot about these things. But I would like someone to comment on this (so that maybe I will know something!): 1) I thought the poor insert performance was due to a "locality of access" in the index creation, hence I thought that sincethe timestamp is always increasing putting it as first column in the index should give a better insert speed, but itdidn't: why???? 2) I thought that given a query like: select * from taba where clientid=2 and sensor=4 and timestamp between 'start_t' and 'end_t' there shouldn't be a huge difference in speed between an index defined as (timestamp, clientid, sensorid) and another onedefined as (clientid, sensor, timestamp) but I was VERY wrong: it's 1000 times worst. How is it possible??? It's obvious I don't know how multicolumn indexes work... Can someone explain?
В списке pgsql-general по дате отправления: