Re: [PERFORM] Defining performance.

Tobias Brox wrote: [EMAIL PROTECTED] - Thu at 06:37:12PM -0600] As my dataset has gotten larger I have had to throw more metal at the problem, but I have also had to rethink my table and query design. Just because your data set grows linearly does NOT mean that the performance of your query is

Re: [PERFORM] SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can

Joshua D. Drake wrote: On Mon, 2006-12-11 at 14:33 +1100, Chris wrote: Marcos Borges wrote: 07/12/2006 04:31 *SQL_CALC_FOUND_ROWS in POSTGRESQL* In mysqln i m using the command SQL_CALC_FOUND_ROWS in follow sintax. SELECT SQL_CALC_FOUND_ROWS name, email, tel FROM mytable WHERE name

Re: [PERFORM] SQL_CALC_FOUND_ROWS in POSTGRESQL / Some one can

Mark Kirkwood wrote: Chris wrote: It's the same as doing a select count(*) type query using the same clauses, but all in one query instead of two. It doesn't return any extra rows on top of the limit query so it's better than using pg_numrows which runs the whole query and

Re: [PERFORM] Writting a "search engine" for a pgsql DB

Madison Kelly wrote: Hi all, I am asking in this list because, at the end of the day, this is a performance question. I am looking at writing a search engine of sorts for my database. I have only ever written very simple search engines before which amounted to not much more that the que

Re: [PERFORM] Best OS for Postgres 8.2

David Levy wrote: Hi, I am about to order a new server for my Postgres cluster. I will probably get a Dual Xeon Quad Core instead of my current Dual Xeon. Which OS would you recommend to optimize Postgres behaviour (i/o access, multithreading, etc) ? I am hesitating between Fedora Core 6, CentO

Re: [PERFORM] Best OS for Postgres 8.2

[EMAIL PROTECTED] wrote: On Tue, 8 May 2007, Chris wrote: David Levy wrote: Hi, I am about to order a new server for my Postgres cluster. I will probably get a Dual Xeon Quad Core instead of my current Dual Xeon. Which OS would you recommend to optimize Postgres behaviour (i/o access

Re: [PERFORM] Postgres Benchmark Results

I am re-running it with other tuning, notably cost-based vacuum delay and less frequent checkpoints, and it is a *lot* smoother. These take a full night to run, so I'll post more results when I have usefull stuff to show. This has proven to be a very interesting trip to benchmarkla

[PERFORM] update query taking too long

Hi all, I'm trying to do an update of a reasonably large table and it's taking way too long so I'm trying to work out why and if I need to tweak any settings to speed it up. The table is around 3.5 million records. The query is update table set domainname=substring(emailaddress from positio

Re: [PERFORM] update query taking too long

Tom Lane wrote: Chris <[EMAIL PROTECTED]> writes: I'm trying to do an update of a reasonably large table and it's taking way too long so I'm trying to work out why and if I need to tweak any settings to speed it up. Any foreign keys leading to or from that table? Nope

Re: [PERFORM] update query taking too long

A. Kretschmer wrote: am Thu, dem 28.06.2007, um 15:03:32 +1000 mailte Chris folgendes: Hi all, I'm trying to do an update of a reasonably large table and it's taking way too long so I'm trying to work out why and if I need to tweak any settings to speed it up. The tabl

Re: [PERFORM] update query taking too long

A. Kretschmer wrote: am Thu, dem 28.06.2007, um 16:16:50 +1000 mailte Chris folgendes: Is there a better way to write the update? I thought about something like this (but couldn't get it working - guess I don't have the right syntax): update t1 set domainname=(select id,

Re: [PERFORM] update query taking too long

Richard Huxton wrote: Chris wrote: Tom Lane wrote: Any foreign keys leading to or from that table? Nope :( 3.5 million row updates are not exactly gonna be instantaneous anyway, but only FK checks or really slow user-written triggers would make it take upwards of an hour ... No triggers

Re: [PERFORM] update query taking too long

Richard Huxton wrote: Chris wrote: db=# UPDATE email_upd_test SET domainname=substring(email from position('@' in email)); UPDATE 100 Time: 43796.030 ms I think I'm I/O bound from my very limited understanding of vmstat. Well, 43 seconds to update 1 million rows suggests

Re: [PERFORM] Query performance issue

Jonathan Gray wrote: We’re experiencing a query performance problem related to the planner and its ability to perform a specific type of merge. We have created a test case (as attached, or here: http://www3.streamy.com/postgres/indextest.sql) which involves a hypothetical customer ordering

Re: [PERFORM] Query performance issue

Chris wrote: Jonathan Gray wrote: We’re experiencing a query performance problem related to the planner and its ability to perform a specific type of merge. We have created a test case (as attached, or here: http://www3.streamy.com/postgres/indextest.sql) which involves a hypothetical

Re: [PERFORM] Query performance issue

Jonathan Gray wrote: Chris, Creating indexes on the customerclass table does speed up the queries but still does not create the plan we are looking for (using the double index with a backward index scan on the orders table). Stupid question - why is that particular plan your "goal&

Re: [PERFORM] Partitioning in postgres - basic question

Tore Lukashaugen wrote: Hi, I am new to postgres having worked with Oracle in the past. I am interested in understanding Postgres's table partition functionality better. Specifically, I have a third party application running against my postgres database, but the database is becoming rather la

[PERFORM] stats collector suddenly causing lots of IO

I have a lot of centos servers which are running postgres. Postgres isn't used that heavily on any of them, but lately, the stats collector process keeps causing tons of IO load. It seems to happen only on servers with centos 5. The versions of postgres that are running are: 8.1.18 8.2.6 8.3.1 8

[PERFORM] stats collector suddenly causing lots of IO

I have a lot of centos servers which are running postgres. Postgres isn't used that heavily on any of them, but lately, the stats collector process keeps causing tons of IO load. It seems to happen only on servers with centos 5. The versions of postgres that are running are: 8.1.18 8.2.6 8.3.1 8

[PERFORM] planner index choice

Hi there, I have a simple query where I don't understand the planner's choice to use a particular index. The main table looks like this: # \d sq_ast_attr_val Table "public.sq_ast_attr_val" Column| Type | Modifiers -+-

Re: [PERFORM] planner index choice

Hi, Hrm ... are you *certain* that's an 8.4 server? Yep. # psql -U postgres -d db psql (8.4.4) db=# select version(); version --

Re: [PERFORM] good old VACUUM FULL

On 23/03/11 11:52, felix wrote: I posted many weeks ago about a severe problem with a table that was obviously bloated and was stunningly slow. Up to 70 seconds just to get a row count on 300k rows. I removed the text column, so it really was just a few columns of fixed data. Still very bloated.

Re: [PERFORM] Optimizing performance of a like '%...%' condition

Indexing the t_name.name field, I can increase speed, but only if I restrict my search to something like : select * from t_name where t_name.name like 'my_search%' (In this case it takes generally less than 1 second) My question : Are there algorithms or tools that can speed up such a type o

Re: [PERFORM] Creating a correct and real benchmark

PFC wrote: I'm developing a search engine using the postgresql's databas. I've already doing some tunnings looking increase the perform. Now, I'd like of do a realistic test of perfom with number X of queries for know the performance with many queries. What the corret way to do this?

Re: [PERFORM] Joins and full index scans...mysql vs postgres?

ryan groth wrote: I am issing a query like this: SELECT * FROM users users LEFT JOIN phorum_users_base ON users.uid = phorum_users_base.user_id LEFT JOIN useraux ON useraux.uid = users.uid; I'm not sure if postgres would rewrite your query to do the joins properly, though I guess so

Re: [PERFORM] Help understanding indexes, explain, and optimizing

i.v.r. wrote: Hi everyone, I'm experimenting with PostgreSQL, but since I'm no expert DBA, I'm experiencing some performance issues. Please take a look at the following query: SELECT /*groups."name" AS t2_r1, groups."id" AS t2_r3, groups."user_id" AS t2_r0, groups."pretty_url" AS t2_r2,

Re: [PERFORM] pgCluster and postgres 8.1

Javier Somoza wrote: I wanna test my system performance when using pgCluster. I'm using postgreSQL 8.1.0 and i've downloaded pgcluster-1.5.0rc7 and pgcluster-1.5.0rc7-patch. Do i need to recompile postgreSQL with the patch? Can i use pgcluster-1.5 with thi

[PERFORM] import performance

Hi all, I'm trying to work out why my 8.1 system is slower than my 7.4 system for importing data. The import is a lot of "insert into" commands - it's a converted database from another system so I can't change it to copy commands. My uncommented config options: autovacuum = off bgwriter

Re: [PERFORM] import performance

Gavin Sherry wrote: On Tue, 14 Mar 2006, Chris wrote: Hi all, I'm trying to work out why my 8.1 system is slower than my 7.4 system for importing data. The import is a lot of "insert into" commands - it's a converted database from another system so I can't c

Re: [PERFORM] import performance

Frank Wiles wrote: On Tue, 14 Mar 2006 12:24:22 +1100 Chris <[EMAIL PROTECTED]> wrote: Gavin Sherry wrote: On Tue, 14 Mar 2006, Chris wrote: Hi all, I'm trying to work out why my 8.1 system is slower than my 7.4 system for importing data. The import is a lot of "inser

Re: [PERFORM] import performance

Tom Lane wrote: Chris <[EMAIL PROTECTED]> writes: Tons of difference :/ Have you checked that the I/O performance is comparable? It seems possible that there's something badly misconfigured about the disks on your new machine. Benchmarking with "bonnie" or some such

Re: [PERFORM] import performance

David Lang wrote: On Tue, 14 Mar 2006, Chris wrote: The only other thing I can see is the old server is ext2: /dev/hda4 on / type ext2 (rw,errors=remount-ro) the new one is ext3: /dev/hda2 on / type ext3 (rw) this is actually a fairly significant difference. with ext3 most of your data

Re: [PERFORM] Slow SELECTS after large update cycle

Jan de Visser wrote: Hello, After fixing the hanging problems I reported here earlier (by uninstalling W2K3 SP1), I'm running into another weird one. After doing a +/- 8hr cycle of updates and inserts (what we call a 'batch'), the first 'reporting' type query on tables involved in that write

Re: [PERFORM] simple join uses indexes, very slow

george young wrote: [PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.0.1] I have a simple join on two tables that takes way too long. Can you help me understand what's wrong? There are indexes defined on the relevant columns. I just did a fresh vacuum --full --analyze on the

Re: [PERFORM] Slow performance on Windows .NET and OleDb

Ruben Rubio Rey wrote: Greg Quinn wrote: The query is, select * from users which returns 4 varchar fields, there is no where clause Yes, I am running the default postgres config. Basically I have been a MySQL user and thought I would like to check out PostGreSql. So I did a quick performan

Re: [PERFORM] Inserts optimization?

Francisco Reyes wrote: Doing my first write heavy database. What settings will help improve inserts? Only a handfull of connections, but each doing up to 30 inserts/second. Plan to have 2 to 3 clients which most of the time will not run at the same time, but ocasionaly it's possible two of them

Re: [PERFORM] Easy question

e the performance. The index will have entries like: CHRIS BERT JOE and so on. If you run a query like: select * from table where UPPER(name) = 'CHRIS'; It's an easy match. If you don't create an UPPER index, it has to do a comparison with each row - so the index can't b

Re: [PERFORM] Postgres gets stuck

This is a deadly bug, because our web site goes dead when this happens, and it requires an administrator to log in and kill the stuck postgres process then restart Postgres. We've installed failover system so that the web site is diverted to a backup server, but since this has happened twice

Re: [PERFORM] UNSUBSCRIBE

Shoaib Burq wrote: UNSUBSCRIBE To unsubscribe: List-Unsubscribe: Email admins - Could we add this above or below the random tips that get appended to every email ? -- Postgresql & php tutorials http://www.designmagick.com/ ---(end of b

Re: [PERFORM] UNSUBSCRIBE

Tom Lane wrote: Chris <[EMAIL PROTECTED]> writes: Email admins - Could we add this above or below the random tips that get appended to every email ? You mean like these headers that already get added to every list message (these copied-and-pasted from your own message): The headers

Re: [PERFORM] Speed Up Offset and Limit Clause

Christian Paul Cosinas wrote: Hi! How can I speed up my server's performance when I use offset and limit clause. For example I have a query: SELECT * FROM table ORDER BY id, name OFFSET 10 LIMIT 1 This query takes a long time about more than 2 minutes. If my query is: SELECT * FROM ta

Re: [PERFORM] optimizing LIKE '%2345' queries

Gene wrote: Thanks for the suggestion. Actually I went ahead and created a reverse function using plpgsql, created an index using reverse column and now my queries use "where reverse(column) like reverse('%2345') and it's using the index like i hoped it would! Now if I could figure out how to opt

Re: [PERFORM] managing database with thousands of tables

Eugeny N Dzhurinsky wrote: On Wed, Jul 05, 2006 at 09:39:31AM -0400, Tom Lane wrote: Eugeny N Dzhurinsky <[EMAIL PROTECTED]> writes: but it seems pg_autovacuum does not do vacuuming on system tables. There was a bug awhile back whereby autovac failed to notice temp table cleanup at connection

Re: [PERFORM] Query plan issue when upgrading to postgres 8.14 (from

Ioana Danes wrote: I have a problem with a query that in postgres 7.4 and 8.12 has an acceptable response time but in postgres 8.14 is very slow. This is the table I use: * create* *table* TEST ( TESTIDINT8 *not* *null*, TESTTYPE INT4 *null*, *constraint* PK_TESTID *primary* *key* (TES

Re: [PERFORM] setting up foreign keys

Sue Fitt wrote: Hi all, This is my first post to the performance list, I hope someone can help me. I'm setting up a table with 2 columns, both of which reference a column in another table: CREATE TABLE headwords_core_lexemes ( core_id int REFERENCES headwords_core(core_id), lexeme_id int REF

Re: [PERFORM] setting up foreign keys

Sue Fitt wrote: Thanks Chris and Chris, you've solved it. I had a gui open that connects to the database. It was doing nothing (and not preventing me adding to or altering headwords_core via psql), but having closed it the table is instantly created. Weird. BTW, referencing the same c

Re: [PERFORM] setting up foreign keys

Merlin Moncure wrote: On 8/10/06, Chris <[EMAIL PROTECTED]> wrote: Sue Fitt wrote: > Thanks Chris and Chris, you've solved it. > > I had a gui open that connects to the database. It was doing nothing > (and not preventing me adding to or altering headwords_core via psql),

Re: [PERFORM] setting up foreign keys

Spiegelberg, Greg wrote: Sort of on topic, how many foreign keys in a single table is good v. bad? I realize it's relative to the tables the FK's reference so here's an example: Table A: 300 rows Table B: 15,000,000 rows Table C: 100,000 rows Table E: 38 rows Table F: 9 rows Table G: is partiti

Re: [PERFORM] Query tuning

Subbiah, Stalin wrote: Hello All, This query runs forever and ever. Nature of this table being lots of inserts/deletes/query, I vacuum it every half hour to keep the holes reusable and nightly once vacuum analyze to update the optimizer. We've got index on eventtime only. Running it for current

Re: [PERFORM] Query tuning

Subbiah, Stalin wrote: Actually these servers will be upgraded to 8.1.4 in couple of months. even so, you could get some bad data in there. http://www.postgresql.org/docs/8.0/static/release.html . Go through the old release notes and you'll find various race conditions, crashes etc. Here yo

Re: [PERFORM] Forcing index usage without 'enable_hashjoin = FALSE'

Dan Langille wrote: I'm using PostgreSQL 8.1.4 and I'm trying to force the planner to use an index. With the index, I get executions times of 0.5 seconds. Without, it's closer to 2.5 seconds. Compare these two sets of results (also provided at http://rafb.net/paste/results/ywcOZP66.html sho

Re: [PERFORM] data=writeback

rumoured to be the highest- throughput option. It guarantees internal file system integrity, however it can allow old data to appear in files after a crash and journal recovery. How does this relate to fflush()? Does fflush still garantee all data has ben written? Bye, Chris. ---

Re: [PERFORM] data=writeback

the mounter distinguish the two partitions? Maybe I'm missing a concept here, but I thought labels must uniquely identify partitions? Seems suspicious to me... Does it work? When you give just "mount" at the command line what output do you get? Bye, Chris. --

Re: [PERFORM] Join Query Perfomance Issue

Nested Loop (cost=0.00..31157.91 rows=3054 width=14) (actual time=0.252..149.557 rows=2769 loops=1) -> Index Scan using messungen_v_dat_2007_11_12_messpunkt_minute_tag_idx on messungen_v_dat_2007_11_12 m (cost=0.00..5134.28 rows=3054 width=4) (actual time=0.085..11.562 rows=2769 loops=1)

Re: [PERFORM] 7 hrs for a pg_restore?

When I said "obfuscating" I meant it. I'm pretty familiar with sh scripting and I'm not even sure what the && behaviour would do. It chains commands together so if the first fails the second doesn't happen. $ echo 1 && echo 2 1 2 $ echo '1234' > /etc/file_that_doesnt_exist && echo 2 -bash: /

Re: [PERFORM] 7 hrs for a pg_restore?

Gregory Stark wrote: "Chris" <[EMAIL PROTECTED]> writes: When I said "obfuscating" I meant it. I'm pretty familiar with sh scripting and I'm not even sure what the && behaviour would do. It chains commands together so if the first fails the second

Re: [PERFORM] Confirmação de envio / Sending confirmation (captchaid:13266b20536d)

petchimuthu lingam wrote: C5BK4513 Ahh - you are sending this to the wrong address, these are not being sent by the postgres mailing list. Check which address you are replying to next time... -- Postgresql & php tutorials http://www.designmagick.com/ -- Sent via pgsql-performance mailing l

Re: [PERFORM] count * performance issue

sathiya psql wrote: count(*) tooks much time... but with the where clause we can make this to use indexing,... what where clause we can use?? Am using postgres 7.4 in Debian OS with 1 GB RAM, am having a table with nearly 50 lakh records, Looks suspiciously like a question asked yesterday:

Re: [PERFORM] migration of 7.4 to 8.1

sathiya psql wrote: This might be a silly question, but ... why 8.1 ? If you're doing a major upgrade, why not go straight to 8.3? It's been out long enough that there aren't any obvious nasty bugs, and there have been a fair few fixes and improvements since prior versions. Beca

Re: [PERFORM] migration of 7.4 to 8.1

[EMAIL PROTECTED] wrote: On Wed, 12 Mar 2008, sathiya psql wrote: In the home page itself they were saying testing ... unstable you are talking about the debian home page right? then we should not use that for live. so i prefer 8.1 . Debian selected the version of Po

Re: [PERFORM] question on TRUNCATE vs VACUUM FULL

So my question is this: Shouldn’t VACUUM FULL clean Table C and reclaim all its space? You've got concepts mixed up. TRUNCATE deletes all of the data from a particular table (and works in all dbms's). http://www.postgresql.org/docs/8.3/interactive/sql-truncate.html VACUUM FULL is a p

Re: [PERFORM] slow pg_connect()

* Read about configuring and using persistent database connections (http://www.php.net/manual/en/function.pg-pconnect.php) with PHP Though make sure you understand the ramifications of using persistent connections. You can quickly exhaust your connections by using this and also cause other

Re: [PERFORM] bulk insert performance problem

Craig Ringer wrote: Christian Bourque wrote: Hi, I have a performance problem with a script that does massive bulk insert in 6 tables. When the script starts the performance is really good but will degrade minute after minute and take almost a day to finish! Would I be correct in guessing th

Re: [PERFORM] Creating large database of MD5 hash values

1. Which datatype should I use to represent the hash value? UUIDs are also 16 bytes... md5's are always 32 characters long so probably varchar(32). 2. Does it make sense to denormalize the hash set relationships? The general rule is normalize as much as possible then only denormalize whe

Re: [PERFORM] Trigger is not firing immediately

Praveen wrote: > > Hi All, > I am having a trigger in table, If I update the the table manually > trigger is firing immediately(say 200ms per row), But if I update the > table through procedure the trigger is taking time to fire(say 7 to 10 > seconds per row). > > Please tell me what kind o

Re: [PERFORM] limit clause produces wrong query plan

Andrus wrote: Scott, And how exactly should it be optimized? If a query is even moderately interesting, with a few joins and a where clause, postgresql HAS to create the rows that come before your offset in order to assure that it's giving you the right rows. SELECT ... FROM bigtable ORDER B

[PERFORM] left join + case - how is it processed?

Hi all, I have a view that looks like this: SELECT CASE WHEN r.assetid IS NULL THEN p.assetid ELSE r.assetid END AS assetid, CASE WHEN r.userid IS NULL THEN p.userid ELSE r.userid END AS userid, p.permission, p."gra

Re: [PERFORM] left join + case - how is it processed?

The reason why the CASE is affecting your query planning is because you are using a query that compares assetid to a constant: SELECT * from sq_vw_ast_perm where assetid='30748'; When PostgreSQL evaluates this statement, assetid gets expanded either into a case statement (with your first view

Re: [PERFORM] left join + case - how is it processed?

I thought the where condition would cut down on the rows returned, then the case statement would take effect to do the null check. It seems to be doing it in reverse ?? # explain analyze SELECT * from sq_vw_ast_perm where assetid='30748'; It aperas to me that both of your statements have whe

Re: [PERFORM] left join + case - how is it processed?

Tom Lane wrote: Chris writes: I can see it's doing the extra filter step at the start (4th line) which is not present without the coalesce/case statement. I just don't understand why it's being done at that stage. It's not that hard to understand. With the original view

Re: [PERFORM] Any better plan for this query?..

Dimitri wrote: Hi Craig, yes, you detailed very well the problem! :-) all those CHAR columns are so just due historical issues :-) as well they may contains anything else and not only numbers, that's why.. Also, all data inside are fixed, so VARCHAR will not save place, or what kind of performan

Re: [PERFORM] Can Postgres use an INDEX over an OR?

Віталій Тимчишин wrote: 2009/7/20 Robert James > Hi. I notice that when I do a WHERE x, Postgres uses an index, and when I do WHERE y, it does so as well, but when I do WHERE x OR y, it doesn't. Why is this so? It's not clever enough. Of cours

Re: [PERFORM] Will Postgres ever lock with read only queries?

Robert James wrote: Hi. I'm seeing some weird behavior in Postgres. I'm running read only queries (SELECT that is - no UPDATE or DELETE or INSERT is happening at all). I can run one rather complicated query and the results come back... eventually. Likewise with another. But, when I run bot

Re: [PERFORM] Will Postgres ever lock with read only queries?

Robert James wrote: Thanks for the replies. I'm running Postgres 8.2 on Windows XP, Intel Core Duo (though Postgres seems to use only one 1 core). A single query can only use one core, but it will use both if multiple queries come in. The queries are self joins on very large tables, with l

[PERFORM] load / stress testing

Hi, Everyone says "load test using your app" - out of interest how does everyone do that at the database level? I've tried playr (https://area51.myyearbook.com/trac.cgi/wiki/Playr) but haven't been able to get it working properly. I'm not sure what other tools are available. TIA. -- Postgr

Re: [PERFORM] Greenplum MapReduce

Suvankar Roy wrote: Hi all, Has anybody worked on Greenplum MapReduce programming ? It's a commercial product, you need to contact greenplum. -- Postgresql & php tutorials http://www.designmagick.com/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make cha

Re: [PERFORM] improving my query plan

Kevin Kempter wrote: Hi all; I have a simple query against two very large tables ( > 800million rows in theurl_hits_category_jt table and 9.2 million in the url_hits_klk1 table ) I have indexes on the join columns and I've run an explain. also I've set the default statistics to 250 for bot

Re: [PERFORM] Optimizer + bind variables

David Kerr wrote: On Wed, Nov 04, 2009 at 07:43:16AM +0800, Craig Ringer wrote: - David Kerr wrote: - > Does/is it possible for the PG optimizer come up with differnet plans when - > you're using bind variables vs when you send static values? - - Yes, if the bind variable form causes your DB ac

[PERFORM] How to troubleshoot high mem usage by postgres?

extension is at fault here. Regardless of who/what is at fault, I need to fix it. And to do that I need to find out what isn't getting released properly. How would I go about that? Thanks, Chris -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes

Re: [PERFORM] How to troubleshoot high mem usage by postgres?

res log file? If not, where can I find it? Thanks again, Chris -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] How to troubleshoot high mem usage by postgres?

ne with: php -f test3.php Note my comment in the php file <<<<<< UNCOMMENT THIS LINE AND MEMORY ISSUE IS FIXED Thanks for the help everyone. Chris <> -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] [HACKERS] full text search index scan query plan changed in 8.4.2?

Josh Berkus wrote: Xufei, List changed to psql-performance, which is where this discussion belongs. I am testing the index used by full text search recently. I have install 8.3.9 and 8.4.2 separately. In 8.3.9, the query plan is like: postgres=# explain SELECT s.name as source , t.name as

[PERFORM] Hardware advice for scalable warehouse db

TB disks as DAS? Thanks so much! Best, Chris [1]: http://www.b2net.co.uk/netapp/fas3000.pdf -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] performance hit for replication

[EMAIL PROTECTED] ("Joshua D. Drake") writes: >>So, my question is this: My server currently works great, >>performance wise. I need to add fail-over capability, but I'm >>afraid that introducing a stressful task such as replication will >>hurt my server's performance. Is there any foundation to m

Re: [PERFORM] Index bloat problem?

josh@agliodbs.com (Josh Berkus) writes: > Bill, > >> What about if an out-of-the-ordinary number of rows >> were deleted (say 75% of rows in the table, as opposed >> to normal 5%) followed by a 'VACUUM ANALYZE'?  Could >> things get out of whack because of that situation? > > Yes. You'd want to ru

Re: [PERFORM] How can an index be larger than a table

josh@agliodbs.com (Josh Berkus) writes: > David, > >> What also seems weird to me is that the control table has some unique >> indexes created on it, but the data_upate_events table just has a unique >> constraint.  Will postgres use an index in the background to enforce >> this constraint? > > If

Re: [PERFORM] batch inserts are "slow"

[EMAIL PROTECTED] (Christopher Petrilli) writes: > On 5/2/05, Tim Terlegård <[EMAIL PROTECTED]> wrote: >> Howdy! >> >> I'm converting an application to be using postgresql instead of >> oracle. There seems to be only one issue left, batch inserts in >> postgresql seem significant slower than in o

[PERFORM] Kernel Resources and max_connections

ipc.shmmax="66099200" kern.ipc.shmmax and kern.ipc.shmmin will not stay to what I set them to. What am I doing wrong or not doing at all? Your help is greatly appreciated. Regards, Chris. -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.

Re: [PERFORM] Kernel Resources and max_connections

Mark Kirkwood wrote: Chris Hebrard wrote: kern.ipc.shmmax and kern.ipc.shmmin will not stay to what I set them to. What am I doing wrong or not doing at all? These need to go in /etc/sysctl.conf. You might need to set shmall as well. (This not-very-clear distinction between what is sysctl

[PERFORM] Kernel Resources Solved

Problem sovled by setting: kern.ipc.semmni: 280 kern.ipc.semmns: 300 Chris. Mark Kirkwood wrote: Chris Hebrard wrote: kern.ipc.shmmax and kern.ipc.shmmin will not stay to what I set them to. What am I doing wrong or not doing at all? These need to go in /etc/sysctl.conf. You might need to set

Re: [PERFORM] PGSQL Capacity

[EMAIL PROTECTED] writes: > How can i know a capacity of a pg database ? > How many records my table can have ? > I saw in a message that someone have 50 000 records it's possible in a table ? > (My table have 8 string field (length 32 car)). > Thanks for your response. The capacity is much more l

Re: [PERFORM] Prefetch - OffTopic

[EMAIL PROTECTED] ("Mohan, Ross") writes: > for time-series and "insane fast", nothing beats kdB, I believe > > www.kx.com ... Which is well and fine if you're prepared to require that all of the staff that interact with data are skilled APL hackers. Skilled enough that they're all ready to leap

Re: [PERFORM] Mount database on RAM disk?

[EMAIL PROTECTED] (Stuart Bishop) writes: > I'm putting together a road map on how our systems can scale as our > load increases. As part of this, I need to look into setting up some > fast read only mirrors of our database. We should have more than > enough RAM to fit everything into memory. I wou

Re: [PERFORM] PostgresSQL vs. Firebird

mall transactions (autocommit on) with fsync on. Bye, Chris. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

[PERFORM] COPY insert performance

Title: Message I need COPY via libpqxx to insert millions of rows into two tables.  One table has roughly have as many rows and requires half the storage.  In production, the largest table will grow by ~30M rows/day.  To test the COPY performance I split my transactions into 10,000 rows.  I

Re: [PERFORM] COPY insert performance

ork_mem to 512MB and rerun my test. I have 1G of RAM, which is less than we'll be running in production (likely 2G). -Original Message- From: John A Meinel [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 6:09 PM To: Chris Isaacson; Postgresql Performance Subject: Re: [PERFORM

Re: [PERFORM] COPY insert performance

shared_buffers would take care of this. I'll increase work_mem to 512MB and rerun my test. I have 1G of RAM, which is less than we'll be running in production (likely 2G). -Chris -Original Message- From: John A Meinel [mailto:[EMAIL PROTECTED] Sent: Monday, July 25, 2005 6

Re: [PERFORM] COPY insert performance

I need the chunks for each table COPYed within the same transaction which is why I'm not COPYing concurrently via multiple threads/processes. I will experiment w/o OID's and decreasing the shared_buffers and wal_buffers. Thanks, Chris -Original Message- From: Gavin Sherry [mai

Re: [PERFORM] Cheap RAM disk?

[EMAIL PROTECTED] (John A Meinel) writes: > I saw a review of a relatively inexpensive RAM disk over at > anandtech.com, the Gigabyte i-RAM > http://www.anandtech.com/storage/showdoc.aspx?i=2480 And the review shows that it's not *all* that valuable for many of the cases they looked at. > Basical

Re: [PERFORM] Cheap RAM disk?

[EMAIL PROTECTED] ("Jeffrey W. Baker") writes: > I haven't tried this product, but the microbenchmarks seem truly > slow. I think you would get a similar benefit by simply sticking a > 1GB or 2GB DIMM -- battery-backed, of course -- in your RAID > controller. Well, the microbenchmarks were pretty

  1   2   3   4   5   >