Thread: Optimize querry 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 nullidxdo | integer | not nullidxd | integer | not nullnbrq | integer |
default0month | 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
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
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) ->
NestedLoop (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
>
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
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)
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?
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
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.
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