sql - 1 minute difference in almost identical PostgreSQL queries? -


i have rails application ability filter records state_code. noticed when pass 'ca' search term results instantly. if pass 'az' example take more minute though.

i don't have ideas why so?

below query explains psql: fast one:

 explain analyze select    accounts.id  "accounts"  left outer join "addresses"    on "addresses"."addressable_id" = "accounts"."id"    , "addresses"."address_type" = 'mailing'    , "addresses"."addressable_type" = 'account'  "accounts"."organization_id" = 16  , (addresses.state_code in ('ca'))  order accounts.name desc;                                                                        query plan ---------------------------------------------------------------------------------------------------------------------------------------------------------  sort  (cost=4941.94..4941.94 rows=1 width=18) (actual time=74.810..74.969 rows=821 loops=1)    sort key: accounts.name    sort method: quicksort  memory: 75kb    ->  hash join  (cost=4.46..4941.93 rows=1 width=18) (actual time=70.044..73.148 rows=821 loops=1)          hash cond: (addresses.addressable_id = accounts.id)          ->  seq scan on addresses  (cost=0.00..4911.93 rows=6806 width=4) (actual time=0.027..65.547 rows=15244 loops=1)                filter: (((address_type)::text = 'mailing'::text) , ((addressable_type)::text = 'account'::text) , ((state_code)::text = 'ca'::text))                rows removed filter: 129688          ->  hash  (cost=4.45..4.45 rows=1 width=18) (actual time=2.037..2.037 rows=1775 loops=1)                buckets: 1024  batches: 1  memory usage: 87kb                ->  index scan using organization_id_index on accounts  (cost=0.29..4.45 rows=1 width=18) (actual time=0.018..1.318 rows=1775 loops=1)                      index cond: (organization_id = 16)  planning time: 0.565 ms  execution time: 75.224 ms (14 rows) 

slow one:

explain analyze select   accounts.id "accounts" left outer join "addresses"   on "addresses"."addressable_id" = "accounts"."id"   , "addresses"."address_type" = 'mailing'   , "addresses"."addressable_type" = 'account' "accounts"."organization_id" = 16 , (addresses.state_code in ('nv')) order accounts.name desc;                                                                        query plan ---------------------------------------------------------------------------------------------------------------------------------------------------------  sort  (cost=4917.27..4917.27 rows=1 width=18) (actual time=97091.270..97091.277 rows=25 loops=1)    sort key: accounts.name    sort method: quicksort  memory: 26kb    ->  nested loop  (cost=0.29..4917.26 rows=1 width=18) (actual time=844.250..97091.083 rows=25 loops=1)          join filter: (accounts.id = addresses.addressable_id)          rows removed join filter: 915875          ->  index scan using organization_id_index on accounts  (cost=0.29..4.45 rows=1 width=18) (actual time=0.017..10.315 rows=1775 loops=1)                index cond: (organization_id = 16)          ->  seq scan on addresses  (cost=0.00..4911.93 rows=70 width=4) (actual time=0.110..54.521 rows=516 loops=1775)                filter: (((address_type)::text = 'mailing'::text) , ((addressable_type)::text = 'account'::text) , ((state_code)::text = 'nv'::text))                rows removed filter: 144416  planning time: 0.308 ms  execution time: 97091.325 ms (13 rows) 

slow 1 result 25 rows, fast 1 821 rows, more confusing.

i solved using vacuum analyze command psql command line.


Comments

Popular posts from this blog

magento2 - Magento 2 admin grid add filter to collection -

Android volley - avoid multiple requests of the same kind to the server? -

Combining PHP Registration and Login into one class with multiple functions in one PHP file -