From: | David Kerr <dmk(at)mr-paradox(dot)net> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | What would effect planning time? |
Date: | 2012-07-06 02:12:24 |
Message-ID: | 78E55E32-2C73-43EC-A107-ACEFB0C6FC1E@mr-paradox.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I spent a good chunk of today trying to chase down why a query on
one box ran in 110ms and on another, smaller box it ran in 10ms.
There was no other activity on either box.
Both boxes are PG9.1.1 RHEL 6.2 x64. the faster box is a smallish
VM. the other box is a big 40core/256GB box.
The plans between both boxes were exactly the same, so it didn't occur
to me to run an analyze on the tables.
I did a number of things including bouncing the DB and reindexing
some of the tables. that didn't help.
Eventually i separated the query out to a prepared statement and
found that it was spending 100ms in PREPARE on the slow box (I
assume it was planning)
I left the problem for about 30 minutes and came back and the
query started running at normal speed.
I suspect an autovacuum kicked in, but would that sort of thing really impact
parse/plan time to that degree? any other thoughts as to what it could have been?
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-07-06 03:02:34 | Re: [PERFORM] The need for clustered indexes to boost TPC-V performance |
Previous Message | Greg Smith | 2012-07-06 01:45:42 | Re: MemSQL the "world's fastest database"? |