sql performance and cache - Mailing list pgsql-performance
From | Chris Faulkner |
---|---|
Subject | sql performance and cache |
Date | |
Msg-id | DGENKIKMJILAAKJGFHKFEEKECIAA.chrisf@oramap.com Whole thread Raw |
Responses |
Re: sql performance and cache
Re: [SQL] sql performance and cache Re: sql performance and cache Re: [SQL] sql performance and cache |
List | pgsql-performance |
Hello all I have two very similar queries which I need to execute. They both have exactly the same from / where conditions. When I execute the first, it takes about 16 seconds. The second is executed almost immediately after, it takes 13 seconds. In short, I'd like to know why the query result isn't being cached and any ideas on how to improve the execution. The first query attempts to find the maximum size of an array in the result set- the field is called "level". IT contains anything between 1 and 10 integers. I just need to know what the largest size is. I do this to find out the maximum size of the "level" array. "max(replace(split_part(array_dims(level),':',2),']','')::int)" I know this is big and ugly but is there any better way of doing it ? The second query just returns the result set - it has exactly the same FROM/Where clause. OK - so I could execute the query once, and get the maximum size of the array and the result set in one. I know what I am doing is less than optimal but I had expected the query results to be cached. So the second execution would be very quick. So why aren't they ? I have increased my cache size - shared_buffers is 2000 and I have doubled the default max_fsm... settings (although I am not sure what they do). sort_mem is 8192. The from / where is FROM oscar_node N, oscar_point P where N."GEOM_ID_OF_POINT" = P."POINT_ID" and N."TILE_REF" = P."TILE_REF" and N."TILE_REF" in ('TQ27NE','TQ28SE','TQ37NW','TQ38SW') and P."TILE_REF" in ('TQ27NE','TQ28SE','TQ37NW','TQ38SW') and P."FEAT_CODE" = 3500 and P.wkb_geometry && GeometryFromText('BOX3D(529540.0 179658.88,530540.0 180307.12)'::box3d,-1) oscar_node and oscar_point both have about 3m rows. PK on oscar_node is composite of "TILE_REF" and "NODE_ID". PK on oscar_point is "TILE_REF" and "POINT_ID". The tables are indexed on feat_code and I have an index on wkb_geometry. (This is a GIST index). I have increased the statistics size and done the analyze command. Here is my explain plan Nested Loop (cost=0.00..147.11 rows=1 width=148) Join Filter: ("inner"."GEOM_ID_OF_POINT" = "outer"."POINT_ID") -> Index Scan using gidx_oscar_point on oscar_point p (cost=0.00..61.34 rows=1 width=57) Index Cond: (wkb_geometry && 'SRID=-1;BOX3D(529540 179658.88 0,530540 180307.12 0)'::geometry) Filter: ((("TILE_REF" = 'TQ27NE'::bpchar) OR ("TILE_REF" = 'TQ28SE'::bpchar) OR ("TILE_REF" = 'TQ37NW'::bpchar) OR ("TILE_REF" = 'TQ38SW'::bpchar)) AND ("FEAT_CODE" = 3500)) -> Index Scan using idx_on_tile_ref on oscar_node n (cost=0.00..85.74 rows=2 width=91) Index Cond: (n."TILE_REF" = "outer"."TILE_REF") Filter: (("TILE_REF" = 'TQ27NE'::bpchar) OR ("TILE_REF" = 'TQ28SE'::bpchar) OR ("TILE_REF" = 'TQ37NW'::bpchar) OR ("TILE_REF" = 'TQ38SW'::bpchar)) I am seeing this message in my logs. "bt_fixroot: not valid old root page" Maybe this is relevant to my performance problems. I know this has been a long message but I would really appreciate any performance tips. Thanks Chris
pgsql-performance by date: