pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedOptimize querry sql
14+ messages / 5 participants
[nested] [flat]
* Optimize querry sql
@ 2007-09-14 08:31 Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
0 siblings, 1 reply; 14+ messages in thread
From: Stanislas de Larocque @ 2007-09-14 08:31 UTC (permalink / raw)
To: pgsql-sql
Hi,
I want to optimize my qerry sql (execution time : 2448 ms) :
SELECT b.idxreseller, sum(a.nbrq), b.namereseller from stat a
,reseller b where b.asp=6 and a.idxreseller=b.reseller and
a.month=date_part('month',now() - interval '1 month') and
a.year=date_part('year',now() - interval '1 month') GROUP BY
b.idxreseller,b.namereseller limit 15;
dns=> \d stat_dns_domaine;
Table «public.stat_dns_domaine»
idxdxreseller | integer | not null
idxdo | integer | not null
idxd | integer | not null
nbrq | integer | default 0
month | integer | default date_part('month'::text, (now() -
'1 mon'::interval))
year | integer | default date_part('year'::text, (now() - '1
mon'::interval))
Index :
«stat_dns_domaine_idx_idxr_idxrevendeur» btree (idxrevendeur)
«stat_dns_domaine_idx_mois_annee_idxrev» btree (mois, annee, idxrevendeur)
\d revendeur limit 20;
Table «public.revendeur»
idxreseller | integer | not null default
nextval(('idxrevendeur_seq'::text)::regclass)
namereseller | text |
asp | integer |
Index :
«reseller_pkey» PRIMARY KEY, btree (idxreseller)
Thank you
STan
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
@ 2007-09-14 08:49 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 10:26 ` Re: Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 13:36 ` Re: Optimize querry sql Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 2 replies; 14+ messages in thread
From: A. Kretschmer @ 2007-09-14 08:49 UTC (permalink / raw)
To: pgsql-sql
am Fri, dem 14.09.2007, um 10:31:39 +0200 mailte Stanislas de Larocque folgendes:
> Hi,
>
> I want to optimize my qerry sql (execution time : 2448 ms) :
>
> SELECT b.idxreseller, sum(a.nbrq), b.namereseller from stat a
> ,reseller b where b.asp=6 and a.idxreseller=b.reseller and
> a.month=date_part('month',now() - interval '1 month') and
> a.year=date_part('year',now() - interval '1 month') GROUP BY
> b.idxreseller,b.namereseller limit 15;
Show us the output from EXLAIN ANALYSE <your query>.
My guess: you need at least an index in reseller.asp. Why do you have
columns such a.month and a.year? se a regular DATE or TIMESTAMPTZ field
instead and an index on this.
And use CURRENT_DATE instead now().
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
@ 2007-09-14 10:26 ` Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 11:55 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 11:59 ` Re: Optimize querry sql hubert depesz lubaczewski <depesz@depesz.com>
1 sibling, 2 replies; 14+ messages in thread
From: Stanislas de Larocque @ 2007-09-14 10:26 UTC (permalink / raw)
To: A. Kretschmer <andreas.kretschmer@schollglas.com>; +Cc: pgsql-sql
Hi,
Explain my sql querry :
Limit (cost=1057.15..1057.16 rows=1 width=27)
-> HashAggregate (cost=1057.15..1057.16 rows=1 width=27)
-> Nested Loop (cost=0.00..1057.14 rows=1 width=27)
-> Seq Scan on stat a (cost=0.00..1042.98 rows=1 width=8)
Filter: (((month)::double precision =
date_part('month'::text, (now() - '1 mon'::interval))) AND
((year)::double precision = date_part('year'::text, (now() - '1
mon'::interval))))
-> Index Scan using resaller_pkey on revendeur b
(cost=0.00..14.15 rows=1 width=23)
Index Cond: ("outer".idxresaller = b.idxresaller)
Filter: (asp = 6)
I would optimize "Seq Scan on stat a (cost=0.00..1042.98 rows=1 width=8)"
What is your advice ?
Thank you
Stan
2007/9/14, A. Kretschmer <andreas.kretschmer@schollglas.com>:
> am Fri, dem 14.09.2007, um 10:31:39 +0200 mailte Stanislas de Larocque folgendes:
> > Hi,
> >
> > I want to optimize my qerry sql (execution time : 2448 ms) :
> >
> > SELECT b.idxreseller, sum(a.nbrq), b.namereseller from stat a
> > ,reseller b where b.asp=6 and a.idxreseller=b.reseller and
> > a.month=date_part('month',now() - interval '1 month') and
> > a.year=date_part('year',now() - interval '1 month') GROUP BY
> > b.idxreseller,b.namereseller limit 15;
>
> Show us the output from EXLAIN ANALYSE <your query>.
>
> My guess: you need at least an index in reseller.asp. Why do you have
> columns such a.month and a.year? se a regular DATE or TIMESTAMPTZ field
> instead and an index on this.
> And use CURRENT_DATE instead now().
>
> Andreas
> --
> Andreas Kretschmer
> Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
> GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
>
> ---------------------------(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
>
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 10:26 ` Re: Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
@ 2007-09-14 11:55 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
1 sibling, 0 replies; 14+ messages in thread
From: A. Kretschmer @ 2007-09-14 11:55 UTC (permalink / raw)
To: pgsql-sql
am Fri, dem 14.09.2007, um 12:26:00 +0200 mailte Stanislas de Larocque folgendes:
> Hi,
>
> Explain my sql querry :
>
> Limit (cost=1057.15..1057.16 rows=1 width=27)
> -> HashAggregate (cost=1057.15..1057.16 rows=1 width=27)
> -> Nested Loop (cost=0.00..1057.14 rows=1 width=27)
> -> Seq Scan on stat a (cost=0.00..1042.98 rows=1 width=8)
> Filter: (((month)::double precision =
> date_part('month'::text, (now() - '1 mon'::interval))) AND
> ((year)::double precision = date_part('year'::text, (now() - '1
> mon'::interval))))
> -> Index Scan using resaller_pkey on revendeur b
> (cost=0.00..14.15 rows=1 width=23)
> Index Cond: ("outer".idxresaller = b.idxresaller)
> Filter: (asp = 6)
>
> I would optimize "Seq Scan on stat a (cost=0.00..1042.98 rows=1 width=8)"
>
> What is your advice ?
Create indexes on the columns month and year. But, again, you have an
unpractical table-design.
>
> Thank you
>
> Stan
>
>
> 2007/9/14, A. Kretschmer <andreas.kretschmer@schollglas.com>:
Please no top-posting.
(answer on top and fullquote below)
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 10:26 ` Re: Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
@ 2007-09-14 11:59 ` hubert depesz lubaczewski <depesz@depesz.com>
1 sibling, 0 replies; 14+ messages in thread
From: hubert depesz lubaczewski @ 2007-09-14 11:59 UTC (permalink / raw)
To: Stanislas de Larocque <dllstan@gmail.com>; +Cc: A. Kretschmer <andreas.kretschmer@schollglas.com>; pgsql-sql
On Fri, Sep 14, 2007 at 12:26:00PM +0200, Stanislas de Larocque wrote:
> Explain my sql querry :
did you notice, that andreas asked:
> > Show us the output from EXLAIN ANALYSE <your query>.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
@ 2007-09-14 13:36 ` Scott Marlowe <scott.marlowe@gmail.com>
2007-09-14 14:52 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
1 sibling, 1 reply; 14+ messages in thread
From: Scott Marlowe @ 2007-09-14 13:36 UTC (permalink / raw)
To: A. Kretschmer <andreas.kretschmer@schollglas.com>; +Cc: pgsql-sql
On 9/14/07, A. Kretschmer <andreas.kretschmer@schollglas.com> wrote:
> And use CURRENT_DATE instead now().
Out of curiosity, why the advice to switch from now() to CURRENT_DATE?
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 13:36 ` Re: Optimize querry sql Scott Marlowe <scott.marlowe@gmail.com>
@ 2007-09-14 14:52 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 15:17 ` Re: Optimize querry sql Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: A. Kretschmer @ 2007-09-14 14:52 UTC (permalink / raw)
To: pgsql-sql
am Fri, dem 14.09.2007, um 8:36:47 -0500 mailte Scott Marlowe folgendes:
> On 9/14/07, A. Kretschmer <andreas.kretschmer@schollglas.com> wrote:
>
> > And use CURRENT_DATE instead now().
>
> Out of curiosity, why the advice to switch from now() to CURRENT_DATE?
Mhh, don't know...
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 13:36 ` Re: Optimize querry sql Scott Marlowe <scott.marlowe@gmail.com>
2007-09-14 14:52 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
@ 2007-09-14 15:17 ` Scott Marlowe <scott.marlowe@gmail.com>
2007-09-15 14:25 ` Re: Optimize querry sql Michael Glaesemann <grzm@seespotcode.net>
0 siblings, 1 reply; 14+ messages in thread
From: Scott Marlowe @ 2007-09-14 15:17 UTC (permalink / raw)
To: A. Kretschmer <andreas.kretschmer@schollglas.com>; +Cc: pgsql-sql
On 9/14/07, A. Kretschmer <andreas.kretschmer@schollglas.com> wrote:
> am Fri, dem 14.09.2007, um 8:36:47 -0500 mailte Scott Marlowe folgendes:
> > On 9/14/07, A. Kretschmer <andreas.kretschmer@schollglas.com> wrote:
> >
> > > And use CURRENT_DATE instead now().
> >
> > Out of curiosity, why the advice to switch from now() to CURRENT_DATE?
>
> Mhh, don't know...
OK, I was just afraid there was some "bad thing" TM that I wasn't
aware of with now(), which, btw, I use all the time. whew.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 13:36 ` Re: Optimize querry sql Scott Marlowe <scott.marlowe@gmail.com>
2007-09-14 14:52 ` Re: Optimize querry sql A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 15:17 ` Re: Optimize querry sql Scott Marlowe <scott.marlowe@gmail.com>
@ 2007-09-15 14:25 ` Michael Glaesemann <grzm@seespotcode.net>
0 siblings, 0 replies; 14+ messages in thread
From: Michael Glaesemann @ 2007-09-15 14:25 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; +Cc: A. Kretschmer <andreas.kretschmer@schollglas.com>; pgsql-sql
On Sep 14, 2007, at 10:17 , Scott Marlowe wrote:
> OK, I was just afraid there was some "bad thing" TM that I wasn't
> aware of with now(), which, btw, I use all the time. whew.
I use CURRENT_TIMESTAMP and CURRENT_DATE for three reasons:
* they're SQL-standard keywords, unlike now(). This might make it
more portable, but I'm not planning on using another backend any time
soon.
* I think it's clearer to distinguish between timestamps and dates
* I don't like the look of now() with the parens.
Not that these are necessarily good reasons, but they're mine :). I
haven't measured it, but there might actually be (a very small bit
of) overhead in calling CURRENT_TIMESTAMP and CURRENT_DATE as they're
converted to now(), so that's one potential reason not to use them.
Michael Glaesemann
grzm seespotcode net
^ permalink raw reply [nested|flat] 14+ messages in thread
* Optimize querry sql
@ 2007-09-14 08:32 Stanislas de Larocque <dllstan@gmail.com>
0 siblings, 0 replies; 14+ messages in thread
From: Stanislas de Larocque @ 2007-09-14 08:32 UTC (permalink / raw)
To: pgsql-sql
Hi,
I want to optimize my qerry sql (execution time : 2448 ms) :
SELECT b.idxreseller, sum(a.nbrq), b.namereseller from stat a
,reseller b where b.asp=6 and a.idxreseller=b.reseller and
a.month=date_part('month',now() - interval '1 month') and
a.year=date_part('year',now() - interval '1 month') GROUP BY
b.idxreseller,b.namereseller limit 15;
dns=> \d stat_dns_domaine;
Table «public.stat»
idxdxreseller | integer | not null
idxdo | integer | not null
idxd | integer | not null
nbrq | integer | default 0
month | integer | default date_part('month'::text, (now() -
'1 mon'::interval))
year | integer | default date_part('year'::text, (now() - '1
mon'::interval))
Index :
«stat_dns_domaine_idx_idxr_idxrevendeur» btree (idxrevendeur)
«stat_dns_domaine_idx_mois_annee_idxrev» btree (mois, annee, idxrevendeur)
\d revendeur;
Table «public.reseller»
idxreseller | integer | not null default
nextval(('idxrevendeur_seq'::text)::regclass)
namereseller | text |
asp | integer |
Index :
«reseller_pkey» PRIMARY KEY, btree (idxreseller)
Thank you
Stan
^ permalink raw reply [nested|flat] 14+ messages in thread
* Optimize querry sql
@ 2007-09-14 13:02 Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 13:36 ` Re: Optimize querry sql hubert depesz lubaczewski <depesz@depesz.com>
0 siblings, 1 reply; 14+ messages in thread
From: Stanislas de Larocque @ 2007-09-14 13:02 UTC (permalink / raw)
To: pgsql-sql
Hi,
I had errors in my last emails. sorry
I want to optimize my query sql (execution time : 2665 ms) :
SELECT b.idxreseller, sum(a.nbrq), b.namereseller from stat a
,reseller b where b.asp=6 and a.idxreseller=b.reseller and
a.month=date_part('month',now() - interval '1 month') and
a.year=date_part('year',now() - interval '1 month') GROUP BY
b.idxreseller,b.namereseller limit 15;
Explain analyse :
Limit (cost=1057.15..1057.16 rows=1 width=27) (actual
time=2655.083..2655.176 rows=15 loops=1)
-> HashAggregate (cost=1057.15..1057.16 rows=1 width=27) (actual
time=2655.074..2655.132 rows=15 loops=1)
-> Nested Loop (cost=0.00..1057.14 rows=1 width=27) (actual
time=0.646..2464.563 rows=18543 loops=1)
-> Seq Scan on stat a (cost=0.00..1042.98 rows=1
width=8) (actual time=0.273..1239.510 rows=24881 loops=1)
Filter: (((month)::double precision =
date_part('month'::text, (now() - '1 mon'::interval))) AND
((year)::double precision = date_part('year'::text, (now() - '1
mon'::interval))))
-> Index Scan using reseller_pkey on reseller b
(cost=0.00..14.15 rows=1 width=23) (actual time=0.034..0.038 rows=1
loops=24881)
Index Cond: ("outer".idxrreseller = b.idxreseller)
Filter: (asp = 6)
Total runtime: 2655.713 ms
dns=> \d stat;
Table «public.stat»
idxreseller | integer | not null
idxdo | integer | not null
idxd | integer | not null
nbrq | integer | default 0
month | integer | default date_part('month'::text, (now() -
'1 mon'::interval))
year | integer | default date_part('year'::text, (now() - '1
mon'::interval))
Index :
«stat_dns_domaine_idx_idxr_idxreseller» btree (dxreseller)
«stat_dns_domaine_idx_month_year_idxres» btree (month, year, idxreseller)
\d reseller;
Table «public.reseller»
idxreseller | integer | not null default
nextval(('idxrevendeur_seq'::text)::regclass)
namereseller | text |
asp | integer |
Index :
«reseller_pkey» PRIMARY KEY, btree (idxreseller)
Have you advices ?
Thank you
Stan
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 13:02 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
@ 2007-09-14 13:36 ` hubert depesz lubaczewski <depesz@depesz.com>
2007-09-17 07:17 ` Re: Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: hubert depesz lubaczewski @ 2007-09-14 13:36 UTC (permalink / raw)
To: Stanislas de Larocque <dllstan@gmail.com>; +Cc: pgsql-sql
On Fri, Sep 14, 2007 at 03:02:59PM +0200, Stanislas de Larocque wrote:
> I want to optimize my query sql (execution time : 2665 ms) :
SELECT
b.idxreseller,
sum(a.nbrq),
b.namereseller
from
stat a,
reseller b
where
b.asp=6
and a.idxreseller=b.reseller
and a.month=date_part('month',now() - interval '1 month')
and a.year=date_part('year',now() - interval '1 month')
GROUP BY
b.idxreseller,b.namereseller limit 15;
1. cast all date_parts to int4, like in:
a.month = cast( date_part('month',now() - interval '1 month') as int4)
2. why there is a limit without any order by?
3. change it to get namereseller from subselect, not from join.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 13:02 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 13:36 ` Re: Optimize querry sql hubert depesz lubaczewski <depesz@depesz.com>
@ 2007-09-17 07:17 ` Stanislas de Larocque <dllstan@gmail.com>
2007-09-17 07:25 ` Re: Optimize querry sql hubert depesz lubaczewski <depesz@depesz.com>
0 siblings, 1 reply; 14+ messages in thread
From: Stanislas de Larocque @ 2007-09-17 07:17 UTC (permalink / raw)
To: depesz@depesz.com; +Cc: pgsql-sql
Hi,
I deleted the fonction date_part and now the time of the querry is : 464 ms !!!
Limit (cost=1373.32..1373.50 rows=15 width=27) (actual
time=463.762..463.857 rows=15 loops=1)
-> HashAggregate (cost=1373.32..1408.52 rows=2816 width=27)
(actual time=463.755..463.820 rows=15 loops=1)
-> Hash Join (cost=149.72..1189.22 rows=24546 width=27)
(actual time=42.106..348.561 rows=18543 loops=1)
Hash Cond: ("outer".idxreseller = "inner".idxreseller)
-> Seq Scan on stat a (cost=0.00..545.27 rows=24877
width=8) (actual time=0.054..167.340 rows=24881 loops=1)
Filter: ((month = 8) AND (year = 2007))
-> Hash (cost=142.68..142.68 rows=2816 width=23)
(actual time=41.954..41.954 rows=2816 loops=1)
-> Seq Scan on reseller b (cost=0.00..142.68
rows=2816 width=23) (actual time=0.035..28.447 rows=2816 loops=1)
Filter: (asp = 6)
Total runtime: 464.337 ms
Have you advices to optimize the query please ?
Stan
2007/9/14, hubert depesz lubaczewski <depesz@depesz.com>:
> On Fri, Sep 14, 2007 at 03:02:59PM +0200, Stanislas de Larocque wrote:
> > I want to optimize my query sql (execution time : 2665 ms) :
> SELECT
> b.idxreseller,
> sum(a.nbrq),
> b.namereseller
> from
> stat a,
> reseller b
> where
> b.asp=6
> and a.idxreseller=b.reseller
> and a.month=date_part('month',now() - interval '1 month')
> and a.year=date_part('year',now() - interval '1 month')
> GROUP BY
> b.idxreseller,b.namereseller limit 15;
>
> 1. cast all date_parts to int4, like in:
> a.month = cast( date_part('month',now() - interval '1 month') as int4)
> 2. why there is a limit without any order by?
> 3. change it to get namereseller from subselect, not from join.
>
> depesz
>
> --
> quicksil1er: "postgres is excellent, but like any DB it requires a
> highly paid DBA. here's my CV!" :)
> http://www.depesz.com/ - blog dla ciebie (i moje CV)
>
--
Stanislas de Larocque
dllstan@gmail.com
06 63 64 00 47
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: Optimize querry sql
2007-09-14 13:02 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 13:36 ` Re: Optimize querry sql hubert depesz lubaczewski <depesz@depesz.com>
2007-09-17 07:17 ` Re: Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
@ 2007-09-17 07:25 ` hubert depesz lubaczewski <depesz@depesz.com>
0 siblings, 0 replies; 14+ messages in thread
From: hubert depesz lubaczewski @ 2007-09-17 07:25 UTC (permalink / raw)
To: Stanislas de Larocque <dllstan@gmail.com>; +Cc: pgsql-sql
On Mon, Sep 17, 2007 at 09:17:58AM +0200, Stanislas de Larocque wrote:
> Have you advices to optimize the query please ?
for some many rows the 400ms looks quite reasonable.
the best thing you can make to speed things up is to calculate the
counts with triggers.
depesz
--
quicksil1er: "postgres is excellent, but like any DB it requires a
highly paid DBA. here's my CV!" :)
http://www.depesz.com/ - blog dla ciebie (i moje CV)
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2007-09-17 07:25 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-09-14 08:31 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 08:49 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 10:26 ` Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 11:55 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 11:59 ` hubert depesz lubaczewski <depesz@depesz.com>
2007-09-14 13:36 ` Scott Marlowe <scott.marlowe@gmail.com>
2007-09-14 14:52 ` A. Kretschmer <andreas.kretschmer@schollglas.com>
2007-09-14 15:17 ` Scott Marlowe <scott.marlowe@gmail.com>
2007-09-15 14:25 ` Michael Glaesemann <grzm@seespotcode.net>
2007-09-14 08:32 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 13:02 Optimize querry sql Stanislas de Larocque <dllstan@gmail.com>
2007-09-14 13:36 ` hubert depesz lubaczewski <depesz@depesz.com>
2007-09-17 07:17 ` Stanislas de Larocque <dllstan@gmail.com>
2007-09-17 07:25 ` hubert depesz lubaczewski <depesz@depesz.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox