3:04 PM, Bryce Covert <br...@brycecovertoperations.com>
wrote:
Not sure if this is
helpful, but I tried upgrading to 9.2, and here's what I got:
-
Limit (cost=0.00..535.78 rows=50 width=8) (actual
time=1037.376..135043.945 rows=50 loops=1)
Output: premiseaccoun
ricusage_premise_account_id_36bc8999ced10059" btree
(premise_account_id, from_date, usage)
"ix_covered_2" btree (premise_account_id, from_date DESC, usage, id)
Any idea why it's not using that?
Thanks!
Bryce
Claudio Freire
December
d help much here? Using a covered
index, I imagine reads would be limited quite a bit.
Thanks again,
Bryce
Claudio Freire
December 12, 2013
1:35 PM
On Thu, Dec 12, 2013 at
6:16 PM, Bryce Covert <br...@brycecovertoperations.com>
wrote:
Thanks a lot for the help. I'
; instead of plain "explain analyze".
Bryce Covert
December 12, 2013
12:20 PM
I don't have much info on disks, since this is a virtual server on
linode. It is running ubuntu 12.04, 8cpus, 4GB ram, 95GB ext3 volume
(noatime). Hopefully that's helpful.
sample of them).
Also, do run "explain (analyze,
buffers)" instead of plain "explain analyze".
Bryce Covert
December 12, 2013
12:20 PM
I don't have much info on disks, since this is a virtual server on
linode. It is running ubuntu 12.04, 8cpus,
PM, Bryce CovertFor this kind of
diagnostic, you need to include hardware details.OS? Disks?
RAID?
Bryce Covert
December 12, 2013
12:10 PM
Hi,
I'm seeing a slow running query. After some optimization with
indexes,
it appears that the query plan is correct, it's ju
Hi,
I'm seeing a slow running query. After some optimization with indexes,
it appears that the query plan is correct, it's just slow. Running the
query twice, not surprisingly, is very fast, due to OS caching or
shared_buffers caching. If the parameters for the query are different,
however,
