[PERFORM] One huge db vs many small dbs

e thoughts. Thanks Max

[PERFORM] Shared memory usage

Hello. I have a postgres 8.0 and ~400mb database with lots of simple selects using indexes. I've installed pgpool on the system. I've set num_init_children to 5 and here is the top output. One of postmasters is my demon running some insert/update tasks. I see that they all use cpu heavily,

Re: [PERFORM] [GENERAL] Shared memory usage

On Sun, 26 Aug 2007 00:39:52 +0400, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: On Sun, Aug 26, 2007 at 01:22:58AM +0400, Max Zorloff wrote: Hello. I have a postgres 8.0 and ~400mb database with lots of simple selects using indexes. I've installed pgpool on the syste

Re: [PERFORM] [GENERAL] Shared memory usage

On Sun, 26 Aug 2007 00:39:52 +0400, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote: On Sun, Aug 26, 2007 at 01:22:58AM +0400, Max Zorloff wrote: Hello. shared_memory is used for caching. It is filled as stuff is used. If you're not using all of it that means it isn't need

Re: [PERFORM] Shared memory usage

On Mon, 27 Aug 2007 14:21:43 +0400, Adam Tauno Williams <[EMAIL PROTECTED]> wrote: I have a postgres 8.0 and ~400mb database with lots of simple selects using indexes. I've installed pgpool on the system. I've set num_init_children to 5 and here is the top output. One of postmasters is my demo

Re: [PERFORM] Shared memory usage

uld be more appropriate, and I'm only replying to there. Sorry, didn't know that. On Sun, 26 Aug 2007, Max Zorloff wrote: shared_buffers is set to 6, yet they use a minimal part of that. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 11492 postgres 16 0

[PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

9.2 1192 3.2e-04 libpthread-2.5.so 804 2.2e-04 libnetsnmp.so.10.0.3 745 2.0e-04 modclusterd Any input? I can reproduce these numbers consistently. If you need more information then just let me know. By the way, I am a new postgresql user so my experience is limited. Cheers, Max

Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

Well the packages are from the pgdg repo which I would have thought are pretty common? https://public.commandprompt.com/projects/pgcore/wiki -Original Message- From: Robert Haas [mailto:robertmh...@gmail.com] Sent: 10 June 2010 02:52 To: Max Williams Cc: pgsql-performance

Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

How do I tell if it was built with debugging options? -Original Message- From: Devrim GÜNDÜZ [mailto:dev...@gunduz.org] Sent: 10 June 2010 09:30 To: Robert Haas Cc: Max Williams; pgsql-performance@postgresql.org Subject: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading

Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

I'm afraid pg_config is not part of the pgdg packages. -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: 10 June 2010 15:11 To: Max Williams Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to

Re: [PERFORM] Large (almost 50%!) performance drop after upgrading to 8.4.4?

Ah, yes its OFF for 8.4.3 and ON for 8.4.4! Can I just turn this off on 8.4.4 or is it a compile time option? Also is this a mistake or intended? Perhaps I should tell the person who builds the pgdg packages?? Cheers, Max -Original Message- From: Kevin Grittner [mailto:kevin.gritt

[PERFORM] test post

please ignore if this goes through. They've been bouncing and I'm trying to find out why. -m ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[PERFORM] Vacuum takes a really long time, vacuum full required

Hi Folks, This is my _4th_ time trying to post this, me and the mailing list software are fighting. I think it's because of the attachments so I'll just put links to them instead. All apologies if this gets duplicated. I've been having problems maintaining the speed of the database in the long

Re: [PERFORM] Vacuum takes a really long time, vacuum full required

Hi Rod, On Tue, Oct 19, 2004 at 11:40:17AM -0400, Rod Taylor wrote: > > Whatever the case, the database still slows down to a halt after a month or > > so, and I have to go in and shut everything down and do a VACUUM FULL by > > hand. One index (of many many) takes 2000 seconds to vacuum. The wh

Re: [PERFORM] Free PostgreSQL Training, Philadelphia, Oct 30

On Wed, Oct 13, 2004 at 12:21:27PM -0400, Aaron Mulder wrote: > All, > My company (Chariot Solutions) is sponsoring a day of free > PostgreSQL training by Bruce Momjian (one of the core PostgreSQL > developers). The day is split into 2 sessions (plus a Q&A session): > > * Mastering Postgre

Re: [PERFORM] Vacuum takes a really long time, vacuum full required

On Tue, Oct 19, 2004 at 11:40:17AM -0400, Rod Taylor wrote: > > Whatever the case, the database still slows down to a halt after a month or > > so, and I have to go in and shut everything down and do a VACUUM FULL by > > hand. One index (of many many) takes 2000 seconds to vacuum. The whole > > p

[PERFORM] perl garbage collector

Hi, I have a stored procedure written in perl and I doubt that perl's garbage collector is working :-( after a lot of work, postmaster has a size of 1100 Mb and I think that the keyword "undef" has no effects. Before tuning my procedure, does it exist a known issue, a workaround

Re: [PERFORM] perl garbage collector

2005/6/28, Tom Lane <[EMAIL PROTECTED]>: > Jean-Max Reymond <[EMAIL PROTECTED]> writes: > > I have a stored procedure written in perl and I doubt that perl's > > garbage collector is working :-( > > after a lot of work, postmaster has a size of 1100 Mb and I

Re: [PERFORM] perl garbage collector

2005/6/28, Jean-Max Reymond <[EMAIL PROTECTED]>: > For my application (in real life) afer millions of spi_exec_query, it > grows up to 1Gb :-( OK, now in 2 lines: CREATE FUNCTION jmax() RETURNS integer AS $_$use strict; for (my $i=0; $i<1000;$i++) { spi_exec_que

[PERFORM] start time very high

disk and data's on the other disk. It seems that the cost of the first sort is very high on the Sun. How is it possible ? the request: explain analyze select * from XDB_CHILD c1 where c1.doc_id = 100 and

Re: [PERFORM] start time very high

2005/6/30, Jean-Max Reymond <[EMAIL PROTECTED]>: > so the request run in 26.646 ms on the Sun and 0.469ms on my laptop :-( > the database are the same, vacuumed and I think the Postgres (8.0.3) > are well configured. > The Sun has two disks and use the TABLESPACE to have index

[PERFORM]

y experience to confirm this fact ? -- Jean-Max Reymond CKR Solutions Open Source Nice France http://www.ckr-solutions.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

[PERFORM] Surprizing performances for Postgres on Centrino

y experience to confirm this fact ? Some tips to speed up Postgres on non-Centrino processors ? -- Jean-Max Reymond CKR Solutions Open Source Nice France http://www.ckr-solutions.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe comman

Re: [PERFORM] Surprizing performances for Postgres on Centrino

On 7/7/05, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > Do you have the same locale settings on all of them? > interressant: UNICODE on the fast laptop SQL_ASCII on the slowest desktops. is UNICODE database faster than SQL_ASCII ? -- Jean-Max Reymond CKR Solutions Open Sou

Re: [PERFORM] Projecting currentdb to more users

2005/7/12, Mohan, Ross <[EMAIL PROTECTED]>: > From AMD's suit against Intel. Perhaps relevant to some PG/AMD issues. Postgres is compiled with gnu compiler. Isn't it ? I don't know how much can Postgres benefit from an optimized Intel compiler. -- Jean-Max Reymond CKR So

[PERFORM] size of cache

processor activity and confirm that processor is waiting for memory ? does it exist a tool to snapshot postgres activity and understand where we spend time and potentialy avoid the bottleneck ? thanks for your tips. -- Jean-Max Reymond CKR Solutions Open Source Nice France http://www.ckr-sol

Re: [PERFORM] blue prints please

2005/10/26, Sidar López Cruz <[EMAIL PROTECTED]>: > where can i find bests practices for tunning postgresql? http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html -- Jean-Max Reymond CKR Solutions Open Source Nice France http://www.ckr-solutions.com -

Re: [PERFORM] VACUUM FULL does not works.......

;VACUUM FULL" is not doing anything. Please suggest. try VACUUM FULL VERBOSE and report the result. -- Jean-Max Reymond CKR Solutions Open Source Nice France http://www.ckr-solutions.com ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PERFORM] TRUNCATE TABLE

Adriaan van Os a écrit : That's a remarkable advice, because XFS is known to be slow at creating and deleting files, see and . date of article: Fri Jul 25 2003 ! ---(end of broadcast

Re: [PERFORM] Table Statistics with pgAdmin III

there a reason that the other 15 fields have zeros in them? I was thinking that maybe I needed to turn on a setting within my database in order to get statistics reported. it seems that the module pgstattuple is needed -- Jean-Max Reymond CKR Solutions http://www.ckr-solutions.com

Re: [PERFORM] Keeping processes open for re-use

2006/11/10, Joshua D. Drake <[EMAIL PROTECTED]>: I would actually suggest pg_pool over pg_pconnect. Please, can you explain advantages of pg_pool over pg_connect ? -- Jean-Max Reymond CKR Solutions Open Source Nice France http://www.ckr-solutions.com ---(

[PERFORM] Performance with Intel Compiler

hi, has anyone compile Postgres with Intel compiler ? Does it exist a substantial gain of performance ? -- Jean-Max Reymond CKR Solutions http://www.ckr-solutions.com ---(end of broadcast)--- TIP 6: Have you searched our list archives

[PERFORM] Optimizing a request

CREATE INDEX "rubrique_rub_titre_index" ON "public"."rubrique" USING btree ("rub_titre"); I want to optimize the following request and avoid the seq scan on the table article (1000 rows). explain SELECT art_id, art_titre, art_texte, rub_titre FRO

Re: [PERFORM] Optimizing a request

On Tue, 31 Aug 2004 12:15:40 -0700, Josh Berkus <[EMAIL PROTECTED]> wrote: > Those look suspiciously like stock estimates. When was the last time you ran > ANALYZE? the vacuum analyze ran just before the explain -- Jean-Max Reymond CKR Solutions http://www.ckr-s

Re: [PERFORM] Optimizing a request

just increased shared_buffers and effective_cache_size to give advantage of 1 Mb RAM -- Jean-Max Reymond CKR Solutions http://www.ckr-solutions.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Optimizing a request

very odd otherwise that only on row out of 10,000,000 could > match and postgres does not realise this. > > Can you post an explain analyse (not just explain) for this query? yes, of course -- Jean-Max Reymond CKR Solutions http://www.ckr-solutions.com ---

Re: [PERFORM] Optimizing a request

gt; > regards, tom lane > OK, TOM Thanks for your help -- Jean-Max Reymond CKR Solutions http://www.ckr-solutions.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

request: 500x slower, yes 500x. This issue is reported to mysql team but no answer (and correction) Actually, the solution is running with a replication database: 1 node for write request and all the other nodes for read requests and the load balancer is made with round robin solution. -- Jean-

Re: [PERFORM] PostgreSQL clustering VS MySQL clustering

On Thu, 20 Jan 2005 12:13:17 -0700, Steve Wampler <[EMAIL PROTECTED]> wrote: > Mitch Pirtle wrote: > But that's not enough, because you're going to be running separate > postgresql backends on the different hosts, and there are > definitely consistency issues with trying to do that. So far as > I

Re: [PERFORM] Less expensive proprietary or Open source ETL tools

e are open source (but not free...), so i'm asking you to know which is the best software on the market. Talend is a great Open Source tool and is OK with Postgres databases -- Jean-Max Reymond CKR Solutions Open Source http://www.ckr-solutions.com -- Sent via pgsql-performance mailing l

[PERFORM] not using my GIN index in JOIN expression

x27;::text)) AND (cormishtml IS FALSE) AND (length(cormdata) < 2))" " -> Bitmap Index Scan on ix_corm_fulltext_cormdata (cost=0.00..24.11 rows=548 width=0)" "Index Cond: (to_tsvector('french'::regconfig, cormdata) @@ to_tsq

Re: [PERFORM] not using my GIN index in JOIN expression

Le 27/02/2014 15:19, Heikki Linnakangas a écrit : On 02/27/2014 04:06 PM, Jean-Max Reymond wrote: I am running the last version of PostgreSQL 9.3.3 I have two tables detm and corm and a lot of datas in the column cormdata of corm table (1.4 GB). I have a GIN index on cormdata: CREATE INDEX

[PERFORM] Performance of UNION vs IN

(may be x2) and it takes 134 ms ! How is it possible that the optimizer cannot optimize the IN as UNION ? I have a database postgresql 9.3 freshly vacuumed -- Jean-Max Reymond CKR Solutions Open Source http://www.ckr-solutions.com -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] Performance of UNION vs IN

Le 20/03/2014 18:13, Torsten Förtsch a écrit : On 20/03/14 17:57, Jean-Max Reymond wrote: I have a very complex view zinfoexp and running the view as: SELECT * FROM zinfoexp WHERE idmembre in (1,84) take 2700 ms So, I try another syntax: SELECT * FROM zinfoexp WHERE idmembre = 1 union SELECT