[PERFORM] Slow SQL query (14-15 seconds)

903 loops=1) -> Subquery Scan stats_adresses_facturation (cost=32.16..52.48 rows=903 width=16) (actual time=4.604..9.510 rows=903 loops=1) -> HashAggregate (cost=32.16..43.45 rows=903 width=16) (actual time=4.600..6.399 rows=903 loops=1)

Re: [PERFORM] Slow SQL query (14-15 seconds)

; SELECT COUNT(*) FROM clients; count --- 1308 (1 ligne) delivery=> SELECT COUNT(*) 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-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Slow SQL query (14-15 seconds)

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 diffi

Re: [PERFORM] Slow SQL query (14-15 seconds)

=866 width=16) (actual time=4.478..6.306 rows=903 loops=1) -> Seq Scan on societes_adresses_facturation (cost=0.00..26.84 rows=943 width=16) (actual time=0.006..2.174 rows=943 loops=1) Filter: (NOT is_deleted) Total runtime: 137.650

[PERFORM] Slow HashAggregate : How to optimize ?

How can I see which part 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 - b

[PERFORM] Large querie with several EXISTS which will be often runned

nvironment) ? How can I improve that query to be faster ? Thanks really much for your advices about this ! :-) --- Bruno BAGUETTE - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

RE : [PERFORM] Large querie with several EXISTS which will be often runned

are OK or is there some things I could change in order to have as much 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 P

RE : [PERFORM] Query problem

gresql.conf file. Here's a nice article about the postgresql.conf file tuning : http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html Hope this help ! :-) Cheers, --- Bruno BAGUETTE - [EMAIL PROTECTED] ---(end of broadcast)-

[PERFORM] Increase performance of a UNION query that thakes 655.07 msec to be runned ?

parser: parse error at or near "(" at character 59 Do you have another idea to get better performances ? Thanks in advance :-) PS : Note that this database is VACUUMed twice per day (and sometimes more). - Bruno BAGUETTE - [EMAIL PROTECTED]

RE : [PERFORM] Increase performance of a UNION query that thakes 655.07 msec to be runned ?

een added/updated/deleted since several weeks (I'm working on a copy of the production database. And this copy is not accessible for the users). My PostgreSQL version 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

RE : [PERFORM] Increase performance of a UNION query that thakes 655.07 msec to be runned ?

e values for that ? Thanks 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&#

RE : RE : [PERFORM] Increase performance of a UNION query that thakes 655.07 msec to be runned ?

> 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