| From: | Scara Maccai <m_lists(at)yahoo(dot)it> |
|---|---|
| To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Ciprian Dorin Craciun <ciprian(dot)craciun(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Using Postgres to store high volume streams of sensor readings |
| Date: | 2008-11-23 15:07:51 |
| Message-ID: | 352634.56573.qm@web28102.mail.ukl.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> But unfortunately the query speed is not good at all
> because most
> queries are for a specific client (and sensor) in a given
> time
> range...
Maybe I'm wrong, I don't know a lot of these things; but defining the index as (timestamp, clientid, sensor) instead of (clientid, sensor, timestamp) should give you more "locality of access" in the index creation?
I think it would make more sense too, since you are not going to query the db without the timestamp, but maybe you want to query it without the clientid or probe (to get aggregates for example).
Plus: could you give us some numbers about the difference in performance of the selects between the index defined as (timestamp) and defined as (clientid, sensor, timestamp)?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | V S P | 2008-11-23 15:43:37 | Re: [Q]updating multiple rows with Different values |
| Previous Message | Stephen Frost | 2008-11-23 13:28:49 | Re: Using Postgres to store high volume streams of sensor readings |