Re: [PERFORM] Hosted servers with good DB disk performance?

2009-06-11 Thread Dimitri Fontaine
Markus Wanner mar...@bluegap.ch writes: If anybody has ever tried their systems, I'd like to hear back. I wish such an offering would exist for Europe (guess that's just a matter of time). http://www.niftyname.org/ http://lost-oasis.fr/ It seems to be coming very soon, in France :) --

Re: [PERFORM] GiST index performance

2009-06-11 Thread Matthew Wakeling
On Wed, 10 Jun 2009, Tom Lane wrote: Also, no calls to anything including bioseg in the name are recorded, although they are definitely called as the GiST support functions for that data type. I have never had any success in getting gprof to profile functions that are in loadable libraries,

[PERFORM] Postgres replication: dump/restore, PITR, Slony,...?

2009-06-11 Thread Shaul Dar
Hi, Our configuration is as follows: 1. A staging server, which receives new data and updates the DB 2. Two web servers that have copies of the DB (essentially read-only) and answer user queries (with load balancer) Currently we use dump (to SQL file, i.e. pg_dump with no args) + file copy to

Re: [PERFORM] GiST index performance

2009-06-11 Thread Tom Lane
Matthew Wakeling matt...@flymine.org writes: That sucks. However, as another observation, no calls to gistfindnext are recorded in the profile either, and that's in the same source file as gistnext which is recorded. Could it have been inlined? Probably. Shouldn't inlining be switched off

Re: [PERFORM] Postgres replication: dump/restore, PITR, Slony,...?

2009-06-11 Thread Dimitri Fontaine
Hi, Shaul Dar shaul...@gmail.com writes: 1. A staging server, which receives new data and updates the DB 2. Two web servers that have copies of the DB (essentially read-only) and answer user queries (with load balancer) [...] Suggestions? I'd consider WAL Shipping for the staging server

Re: [PERFORM] GiST index performance

2009-06-11 Thread Matthew Wakeling
On Thu, 11 Jun 2009, Tom Lane wrote: Oprofile scares me with the sheer number of options. You can ignore practically all of them; the defaults are pretty sane. Thanks, that was helpful. Here is the top of opreport --long-filenames: CPU: Core 2, speed 1998 MHz (estimated) Counted

Re: [PERFORM] GiST index performance

2009-06-11 Thread Tom Lane
Matthew Wakeling matt...@flymine.org writes: So it seems that btree_gist and bioseg are not using that much CPU at all, compared to core postgres code. In fact, the majority of time seems to be spent in libc. Unfortunately my libc doesn't have any debugging symbols. hmm ... memcpy or qsort

Re: [PERFORM] Postgres replication: dump/restore, PITR, Slony,...?

2009-06-11 Thread Joshua D. Drake
Then there are Slony-I, Buchardo, Mamoth Replicator from CMO, simple replication in Postgres 8.4 and other projects... CMO? :) Joshua D. Drake Suggestions? Thanks, -- Shaul -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training

Re: [PERFORM] Postgres replication: dump/restore, PITR, Slony,...?

2009-06-11 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Then there are Slony-I, Buchardo, Mamoth Replicator from CMO, simple replication in Postgres 8.4 and other projects... CMO? :) Buchardo? :) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200906111229

Re: [PERFORM] Postgres replication: dump/restore, PITR, Slony,...?

2009-06-11 Thread Joshua D. Drake
On Thu, 2009-06-11 at 16:30 +, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Then there are Slony-I, Buchardo, Mamoth Replicator from CMO, simple replication in Postgres 8.4 and other projects... CMO? :) Buchardo? :) A new desert, Buchardo CMO:

Re: [PERFORM] GiST index performance

2009-06-11 Thread Matthew Wakeling
On Thu, 11 Jun 2009, Tom Lane wrote: So it'd be worth converting your functions to V1 style. Does that produce a significant reduction in overhead? (You'll probably say yes, that's the whole point). hmm ... memcpy or qsort maybe? Surprise: CPU: Core 2, speed 1998 MHz (estimated) Counted

Re: [PERFORM] GiST index performance

2009-06-11 Thread Matthew Wakeling
On Thu, 11 Jun 2009, Matthew Wakeling wrote: A quick grep in the postgres source for mcount reveals no hits. No idea what it does - there is no man page for it. Ah - that's part of gprof. I'll recompile without --enable-profiling and try again. Duh. Matthew -- What goes up must come down.

Re: [PERFORM] GiST index performance

2009-06-11 Thread Matthew Wakeling
Okay, I don't know quite what's happening here. Tom, perhaps you could advise. Running opannotate --source, I get this sort of stuff: /* * Total samples for file : .../postgresql-8.4beta2/src/backend/access/gist/gistget.c * * 6880 0.2680 */ and then: :static int64

Re: [PERFORM] GiST index performance

2009-06-11 Thread Tom Lane
Matthew Wakeling matt...@flymine.org writes: The gistnext total doesn't seem to correspond to the amount I get by adding up all the individual lines in gistnest. Hmm, hadn't you determined that some other stuff was being inlined into gistnext? I'm not really sure how opannotate displays such

Re: [PERFORM] Best way to load test a postgresql server

2009-06-11 Thread Erik Aronesty
Technically you can then use pgbench on that set of statements, but I usually just use perl's Benchmark module (i'm sure ruby or java or whatever has a similar tool) (First, I log statements by loading the application or web server with statement logging turned on so I'm not guessing what