Anj Adu wrote:
> The combination index works great. Would adding the combination
> index guarantee that the optimizer will choose that index for
> these kind of queries involving the columns in the combination. I
> verified a couple of times and it picked the right index. Just
> wanted to make s
The combination index works great. Would adding the combination index
guarantee that the optimizer will choose that index for these kind of
queries involving the columns in the combination. I verified a couple
of times and it picked the right index. Just wanted to make sure it
does that consistentl
Appears to have helped with the combination index. I'll need to
eliminate caching effects before making sure its the right choice.
Thanks for the suggestion.
On Tue, Jun 22, 2010 at 7:01 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Anj Adu's message of mar jun 22 17:44:39 -0400
Alvaro Herrera writes:
> Excerpts from Anj Adu's message of mar jun 22 17:44:39 -0400 2010:
>> This query seems unreasonable slow on a well-indexed table (13 million
>> rows). Separate indexes are present on guardid_id , from_num and
>> targetprt columns.
> Maybe you need to vacuum or reindex?
R
I did post the explain analyze..can you please clarify
On Tue, Jun 22, 2010 at 6:10 PM, Joshua D. Drake wrote:
> On Tue, 2010-06-22 at 18:00 -0700, Anj Adu wrote:
>> i have several partitions like this (similar size ...similar data
>> distribution)..these partitions are only "inserted"..never upd
On Tue, 2010-06-22 at 18:00 -0700, Anj Adu wrote:
> i have several partitions like this (similar size ...similar data
> distribution)..these partitions are only "inserted"..never updated.
> Why would I need to vacuum..
>
An explain analyze is what is in order for further diagnosis.
JD
> I can
i have several partitions like this (similar size ...similar data
distribution)..these partitions are only "inserted"..never updated.
Why would I need to vacuum..
I can reindex..just curious what can cause the index to go out of whack.
On Tue, Jun 22, 2010 at 4:44 PM, Alvaro Herrera
wrote:
> Exc
Excerpts from Anj Adu's message of mar jun 22 17:44:39 -0400 2010:
> This query seems unreasonable slow on a well-indexed table (13 million
> rows). Separate indexes are present on guardid_id , from_num and
> targetprt columns.
Maybe you need to vacuum or reindex?
--
Álvaro Herrera
The PostgreS
This query seems unreasonable slow on a well-indexed table (13 million
rows). Separate indexes are present on guardid_id , from_num and
targetprt columns.
The table was analyzed with a default stats target of 600.
Postgres 8.1.9 on 2 cpu quad core 5430 with 32G RAM (work_mem=502400)
6 x 450G 15K
