[PERFORM] slow prepare, lots of semop calls.

2012-07-12 Thread David Kerr
I think my original post here might have gotten caught in a spamtrap, so re-trying, I apologize if it ends up being a duplicate. I also forgot to mention that I'm on PG9.1.1 / RHEL 6.2 x64 I believe this is the reason for the behavior i was seeing in this post as well. http://archives.postgresql

Re: [PERFORM] how could select id=xx so slow?

2012-07-12 Thread Yan Chunlu
got it, thanks! without your help I really have no idea what should be fast and what supposed to be slower. I also find "select" involves a lot of writes: iotop shows: 2789 be/4 postgres 0.00 B 57.34 M 0.00 % 0.00 % postgres: goov conta 192.168.1.129(27300) SELECT I knew that selec

Re: [PERFORM] DELETE vs TRUNCATE explanation

2012-07-12 Thread Jeff Janes
On Thu, Jul 12, 2012 at 4:21 PM, Harold A. Giménez wrote: > > > What is shared_buffers? > > > 1600kB That is really small, so the buffer flushing should not be a problem. Unless you mean 1600MB. > > > This is a rather small schema -- probably a half a dozen tables, and > > > probably about a do

Re: [PERFORM] DELETE vs TRUNCATE explanation

2012-07-12 Thread Harold A. Giménez
Hi, I work with Daniel Farina and was the other engineer who "discovered" this, once again. That is, I got bit by it and have been running TRUNCATE on my test suites for years. On Thursday, July 12, 2012 at 12:15 PM, Jeff Janes wrote: > On Wed, Jul 11, 2012 at 3:51 PM, Daniel Farina (mailt

Re: [PERFORM] DELETE vs TRUNCATE explanation

2012-07-12 Thread Jeff Janes
On Wed, Jul 11, 2012 at 3:51 PM, Daniel Farina wrote: > > Nope. I don't. But an exact crossover is a level of precision I don't > really need, because here are where things stand on a completely > unremarkable test suite on the closest project to me that meets the > "regular web-app" profile case

Re: [PERFORM] how could select id=xx so slow?

2012-07-12 Thread Jeff Janes
On Thu, Jul 12, 2012 at 9:07 AM, Ants Aasma wrote: > On Thu, Jul 12, 2012 at 3:48 PM, Yan Chunlu wrote: >> yes the system seems overloaded, I am dealing with a simple "INSERT" but not >> sure if it is normal that it took more time than the explain estimated: > > The estimated cost is in arbitrary

Re: [PERFORM] how could select id=xx so slow?

2012-07-12 Thread Ants Aasma
On Thu, Jul 12, 2012 at 3:48 PM, Yan Chunlu wrote: > yes the system seems overloaded, I am dealing with a simple "INSERT" but not > sure if it is normal that it took more time than the explain estimated: The estimated cost is in arbitrary units, its purpose is to compare different execution plans

Re: [PERFORM] how could select id=xx so slow?

2012-07-12 Thread Craig Ringer
On 07/12/2012 08:48 PM, Yan Chunlu wrote: explain analyze INSERT INTO vote_content ( thing1_id, thing2_id, name, date) VALUES (1,1, E'1', '2012-07-12T12:34:29.926863+00:00'::timestamptz) QUERY PLAN ---

Re: [PERFORM] how could select id=xx so slow?

2012-07-12 Thread Yan Chunlu
yes the system seems overloaded, I am dealing with a simple "INSERT" but not sure if it is normal that it took more time than the explain estimated: explain analyze INSERT INTO vote_content ( thing1_id, thing2_id, name, date) VALUES (1,1, E'1', '2012-07-12T12:34:29.926863+00:00'::timestamptz)

Re: [PERFORM] DELETE vs TRUNCATE explanation

2012-07-12 Thread Craig Ringer
On 07/12/2012 02:12 PM, Daniel Farina wrote: On Wed, Jul 11, 2012 at 6:41 PM, Craig Ringer wrote: On 07/12/2012 06:51 AM, Daniel Farina wrote: 15x slower. This is a Macbook Air with full disk encryption and SSD disk with fsync off, e.g. a very typical developer configuration. Don't use full