Re: Using Postgres to store high volume streams of sensor readings - Mailing list pgsql-general

From Scara Maccai
Subject Re: Using Postgres to store high volume streams of sensor readings
Date
Msg-id 301912.85421.qm@web28106.mail.ukl.yahoo.com
Whole thread Raw
In response to Using Postgres to store high volume streams of sensor readings  ("Ciprian Dorin Craciun" <ciprian.craciun@gmail.com>)
List 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 by date:

Previous
From: "Ciprian Dorin Craciun"
Date:
Subject: Re: Using Postgres to store high volume streams of sensor readings
Next
From: "Scott Marlowe"
Date:
Subject: Re: Using Postgres to store high volume streams of sensor readings