of the query causes the HashAggregate to be so
slow ?
How can I optimize that view to reduce the execution duration time ?
To be accurate, I'm working on PostgreSQL 8.3.5.
Many thanks in advance for any tips about that ! :-)
Best Regards,
--
Bruno Baguette - bruno.bague...@gmail.com
--
Sent via
..2.297 rows=943 loops=1)
Filter: (NOT is_deleted)
Total runtime: 13618.033 ms
(47 lignes)
Regards,
--
Bruno Baguette
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your
(*) FROM commandes;
count
---
5972
(1 ligne)
One reader told me Gmail was guilty for cutting the lines, so I've put a
copy of the query plan on pastebin.com to keep it readable :
http://pastebin.com/m6434f639
Thanks in advance for any tips !
Regards,
--
Bruno Baguette
--
Sent via pgsql
Le 13/11/08 14:28, Matthew Wakeling a écrit :
On Thu, 13 Nov 2008, Bruno Baguette wrote:
I'm having a problem with this query (below) that takes between 14 and
15 seconds to run, which is too long for the end-user.
I've done a EXPLAIN ANALYZE (below below) but I'm having difficulties
to see
As usual, I've put a copy on pastebin : http://pastebin.com/m7611d419
Regards,
--
Bruno Baguette
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
On Fri, 6 Feb 2004, Bruno BAGUETTE wrote:
In addition to what Tom said, the row estimates look suspiciously
default. You mention vacuuming, but do you ever analyze
the tables?
I run VACUUM FULL ANALYZE with the postgres user on all the
PostgreSQL
databases on the server
is PostgreSQL 7.3.2, I have to ask to the
administrator if it can be upgraded to 7.4 in the production server.
Thanks in advance for your help.
---
Bruno BAGUETTE - [EMAIL PROTECTED]
---(end of broadcast
in advance for your tips :-)
---
Bruno BAGUETTE - [EMAIL PROTECTED]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do
performance as possible
(without de-normalize it because I want to avoid redundancy in my
tables).
Thanks very much for your tips ! :-)
---
Bruno BAGUETTE - [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you
