Skip site navigation (1) Skip section navigation (2)

Strangely Variable Query Performance

From: Steve <cheetah(at)tanabi(dot)org>
To: PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Strangely Variable Query Performance
Date: 2007-04-12 21:03:17
Message-ID: Pine.GSO.4.64.0704121653030.17955@kittyhawk.tanabi.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patchespgsql-performance
Hey there;

On a Postgres 8.2.3 server, I've got a query that is running very slow in 
some cases.  With some work, I've determined the 'slow part' of the query. 
:)  This is a query on a table with like 10 million rows or something like 
that.  encounter_id is an integer and receipt is of type 'date'.

This query runs really slow [minutes] (query and explain below):

select extract(epoch from ds.receipt) from detail_summary ds where
ds.receipt >= '1998-12-30 0:0:0' and
ds.encounter_id in
(8813186,8813187,8813188,8813189,8813190,8813191,8813192,
8813193,8813194,8813195,8813196,8813197,8813198,8813199,
8813200,8813201,8813202,8813203,8813204,8813205,8813206,
8813207,8813208,8813209,8813210,8813211,8813212,8813213,
8813214,8813215,8813216,8813217,8813218,8813219,8813220,
8813221,8813222,8813223,8813224,8813225,8813226,8813227,
8813228,8813229,8813230,8813231,8813232,8813233,8813234,
8813235,8813236,8813237,8813238,8813239,8813240,8813241,
8813242,8813243,8813244,8813245,8813246,8813247,8813248,
8813249,8813250,8813251,8813252,8813253,8813254,8813255,
8813256,8813257,8813258,8813259,8813260,8813261,8813262,
8813263,8813264,8813265,8813266,8813267,8813268,8813269,
8813270,8813271,8813272,8813273,8813274,8813275,8813276,
8813277,8813278,8813279,8813280,8813281,8813282,8813283,
8813284,8815534)

Results in the 'explain' :

  Seq Scan on detail_summary ds  (cost=0.00..1902749.83 rows=9962 width=4)
    Filter: ((receipt >= '1998-12-30'::date) AND (encounter_id = ANY 
('{8813186,8813187,8813188,8813189,8813190,8813191,8813192,8813193,8813194,8813195,8813196,8813197,8813198,8813199,8813200,8813201,8813202,8813203,8813204,8813205,8813206,8813207,8813208,8813209,8813210,8813211,8813212,8813213,8813214,8813215,8813216,8813217,8813218,8813219,8813220,8813221,8813222,8813223,8813224,8813225,8813226,8813227,8813228,8813229,8813230,8813231,8813232,8813233,8813234,8813235,8813236,8813237,8813238,8813239,8813240,8813241,8813242,8813243,8813244,8813245,8813246,8813247,8813248,8813249,8813250,8813251,8813252,8813253,8813254,8813255,8813256,8813257,8813258,8813259,8813260,8813261,8813262,8813263,8813264,8813265,8813266,8813267,8813268,8813269,8813270,8813271,8813272,8813273,8813274,8813275,8813276,8813277,8813278,8813279,8813280,8813281,8813282,8813283,8813284,8815534}'::integer[])))
(2 rows)


Turning enable_seqscan to off results in a slightly more interesting 
explain, but an equally slow query.


HOWEVER!  The simple removal of the receipt date paramater results in a 
fast query, as such:

select extract(epoch from ds.receipt) from detail_summary ds where
ds.encounter_id in
(8813186,8813187,8813188,8813189,8813190,8813191,8813192,
8813193,8813194,8813195,8813196,8813197,8813198,8813199,
8813200,8813201,8813202,8813203,8813204,8813205,8813206,
8813207,8813208,8813209,8813210,8813211,8813212,8813213,
8813214,8813215,8813216,8813217,8813218,8813219,8813220,
8813221,8813222,8813223,8813224,8813225,8813226,8813227,
8813228,8813229,8813230,8813231,8813232,8813233,8813234,
8813235,8813236,8813237,8813238,8813239,8813240,8813241,
8813242,8813243,8813244,8813245,8813246,8813247,8813248,
8813249,8813250,8813251,8813252,8813253,8813254,8813255,
8813256,8813257,8813258,8813259,8813260,8813261,8813262,
8813263,8813264,8813265,8813266,8813267,8813268,8813269,
8813270,8813271,8813272,8813273,8813274,8813275,8813276,
8813277,8813278,8813279,8813280,8813281,8813282,8813283,
8813284 ,8815534)

This query returns instantly and explains as:

  Bitmap Heap Scan on detail_summary ds  (cost=161.00..14819.81 rows=9963 
width=4)
    Recheck Cond: (encounter_id = ANY 
('{8813186,8813187,8813188,8813189,8813190,8813191,8813192,8813193,8813194,8813195,8813196,8813197,8813198,8813199,8813200,8813201,8813202,8813203,8813204,8813205,8813206,8813207,8813208,8813209,8813210,8813211,8813212,8813213,8813214,8813215,8813216,8813217,8813218,8813219,8813220,8813221,8813222,8813223,8813224,8813225,8813226,8813227,8813228,8813229,8813230,8813231,8813232,8813233,8813234,8813235,8813236,8813237,8813238,8813239,8813240,8813241,8813242,8813243,8813244,8813245,8813246,8813247,8813248,8813249,8813250,8813251,8813252,8813253,8813254,8813255,8813256,8813257,8813258,8813259,8813260,8813261,8813262,8813263,8813264,8813265,8813266,8813267,8813268,8813269,8813270,8813271,8813272,8813273,8813274,8813275,8813276,8813277,8813278,8813279,8813280,8813281,8813282,8813283,8813284,8815534}'::integer[]))
    ->  Bitmap Index Scan on detail_summary_encounter_id_idx 
(cost=0.00..160.75 rows=9963 width=0)
          Index Cond: (encounter_id = ANY 
('{8813186,8813187,8813188,8813189,8813190,8813191,8813192,8813193,8813194,8813195,8813196,8813197,8813198,8813199,8813200,8813201,8813202,8813203,8813204,8813205,8813206,8813207,8813208,8813209,8813210,8813211,8813212,8813213,8813214,8813215,8813216,8813217,8813218,8813219,8813220,8813221,8813222,8813223,8813224,8813225,8813226,8813227,8813228,8813229,8813230,8813231,8813232,8813233,8813234,8813235,8813236,8813237,8813238,8813239,8813240,8813241,8813242,8813243,8813244,8813245,8813246,8813247,8813248,8813249,8813250,8813251,8813252,8813253,8813254,8813255,8813256,8813257,8813258,8813259,8813260,8813261,8813262,8813263,8813264,8813265,8813266,8813267,8813268,8813269,8813270,8813271,8813272,8813273,8813274,8813275,8813276,8813277,8813278,8813279,8813280,8813281,8813282,8813283,8813284,8815534}'::integer[]))


Any thoughts?  Both encounter_id and receipt date are indexed columns. 
I've vacuumed and analyzed the table.  I tried making a combined index of 
encounter_id and receipt and it hasn't worked out any better.


Thanks!


Steve

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2007-04-12 21:24:52
Subject: Re: Strangely Variable Query Performance
Previous:From: Carlos MorenoDate: 2007-04-12 19:10:18
Subject: Re: Slow Postgresql server

pgsql-hackers by date

Next:From: Luke LonerganDate: 2007-04-12 21:06:52
Subject: Re: TOASTing smaller things
Previous:From: Tom LaneDate: 2007-04-12 20:40:20
Subject: Re: TOASTing smaller things

pgsql-patches by date

Next:From: Tom LaneDate: 2007-04-12 21:24:52
Subject: Re: Strangely Variable Query Performance
Previous:From: Alvaro HerreraDate: 2007-04-12 20:33:06
Subject: autovacuum multiworkers, patch 8

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group