Обсуждение: Perfrmance Problems (7.4.6)

Hi,

I am running on postgres 7.4.6.
I did a vacuum analyze on the database but there was no change.
I Attached here a file with details about the tables, the queries and
the Explain analyze plans.
Hope this can be helpful to analyze my problem

10x
Doron

I think that the problem is the GROUP BY (datetime) that is
date_trunc('hour'::text, i.entry_time)
You should create an indexe with this expression (if its possible).

http://www.postgresql.org/docs/7.4/interactive/indexes-expressional.html

If is not possible, I would create a column with value
date_trunc('hour'::text, i.entry_time) of each row and then index it.

Hope this helps :)

Doron Baranes wrote:

>Hi,
>
>I am running on postgres 7.4.6.
>I did a vacuum analyze on the database but there was no change.
>I Attached here a file with details about the tables, the queries and
>the Explain analyze plans.
>Hope this can be helpful to analyze my problem
>
>10x
>Doron
>
>
>------------------------------------------------------------------------
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>
>

Ok. But that means I need a trigger on the original column to update the
new column on each insert/update and that overhead.

-----Original Message-----
From: Ruben Rubio Rey [mailto:ruben@rentalia.com]
Sent: Thursday, April 20, 2006 12:49 PM
To: Doron Baranes; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Perfrmance Problems (7.4.6)

I think that the problem is the GROUP BY (datetime) that is
date_trunc('hour'::text, i.entry_time)
You should create an indexe with this expression (if its possible).

http://www.postgresql.org/docs/7.4/interactive/indexes-expressional.html

If is not possible, I would create a column with value
date_trunc('hour'::text, i.entry_time) of each row and then index it.

Hope this helps :)

Doron Baranes wrote:

>Hi,
>
>I am running on postgres 7.4.6.
>I did a vacuum analyze on the database but there was no change.
>I Attached here a file with details about the tables, the queries and
>the Explain analyze plans.
>Hope this can be helpful to analyze my problem
>
>10x
>Doron
>
>
>-----------------------------------------------------------------------
-
>
>
>---------------------------(end of
broadcast)---------------------------
>TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>
>

Did you tried to index the expression?
Did it work?

Doron Baranes wrote:

>Ok. But that means I need a trigger on the original column to update the
>new column on each insert/update and that overhead.
>
>-----Original Message-----
>From: Ruben Rubio Rey [mailto:ruben@rentalia.com]
>Sent: Thursday, April 20, 2006 12:49 PM
>To: Doron Baranes; pgsql-performance@postgresql.org
>Subject: Re: [PERFORM] Perfrmance Problems (7.4.6)
>
>I think that the problem is the GROUP BY (datetime) that is
>date_trunc('hour'::text, i.entry_time)
>You should create an indexe with this expression (if its possible).
>
>http://www.postgresql.org/docs/7.4/interactive/indexes-expressional.html
>
>If is not possible, I would create a column with value
>date_trunc('hour'::text, i.entry_time) of each row and then index it.
>
>Hope this helps :)
>
>Doron Baranes wrote:
>
>
>
>>Hi,
>>
>>I am running on postgres 7.4.6.
>>I did a vacuum analyze on the database but there was no change.
>>I Attached here a file with details about the tables, the queries and
>>the Explain analyze plans.
>>Hope this can be helpful to analyze my problem
>>
>>10x
>>Doron
>>
>>
>>-----------------------------------------------------------------------
>>
>>
>-
>
>
>>---------------------------(end of
>>
>>
>broadcast)---------------------------
>
>
>>TIP 9: In versions below 8.0, the planner will ignore your desire to
>>      choose an index scan if your joining column's datatypes do not
>>      match
>>
>>
>>
>>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: Don't 'kill -9' the postmaster
>
>
>
>