Re: [PERFORM] Performances with new Intel Core* processors

2006-08-01 Thread Luke Lonergan
Vivek, On 7/31/06 2:04 PM, Vivek Khera [EMAIL PROTECTED] wrote: No, but it *does* matter how fast said processor can sling the memory around, and in my experience, the opterons have been much better at that due to the efficiency of the memory transport layer. My Mac laptop with a Core 1 and

Re: [PERFORM] Performances with new Intel Core* processors

2006-08-01 Thread Florian Weimer
* Arjen van der Meijden: For a database system, however, processors hardly ever are the main bottleneck, are they? Not directly, but the choice of processor influences which chipsets/mainboards are available, which in turn has some impact on the number of RAM slots. (According to our hardware

Re: [PERFORM] Are there any performance penalty for opposite edian platform combinations....

2006-08-01 Thread Tom Lane
Guoping Zhang [EMAIL PROTECTED] writes: In fact, it is a general question that Is it a good practice we shall avoid to run application server and database server on the platform with opposite edian? or it simply doesn't matter? Our network protocol uses big-endian consistently, so there will

[PERFORM] Query/database optimization

2006-08-01 Thread Eugeny N Dzhurinsky
Hello, I have a query: explain analyze select tu.url_id, tu.url, coalesce(sd.recurse, 100), case when COALESCE(get_option('use_banner')::integer,0) = 0 then 0 else ts.use_banner end as use_banner, ts.use_cookies, ts.use_robots, ts.includes, ts.excludes, ts.track_domain,

Re: Fwd: [PERFORM] Savepoint performance

2006-08-01 Thread Ernest Nishiseki
Actually, what we did in the tests at EnterpriseDB was encapsulate each SQL statement within its own BEGIN/EXCEPTION/END block. Using this approach, if a SQL statement aborts, the rollback is confined  to the BEGIN/END block that encloses it.  Other SQL statements would not be affected since the

[PERFORM] PITR performance overhead?

2006-08-01 Thread George Pavlov
I am looking for some general guidelines on what is the performance overhead of enabling point-in-time recovery (archive_command config) on an 8.1 database. Obviously it will depend on a multitude of factors, but some broad-brush statements and/or anecdotal evidence will suffice. Should one worry

Re: [PERFORM] PITR performance overhead?

2006-08-01 Thread Bill Moran
In response to George Pavlov [EMAIL PROTECTED]: I am looking for some general guidelines on what is the performance overhead of enabling point-in-time recovery (archive_command config) on an 8.1 database. Obviously it will depend on a multitude of factors, but some broad-brush statements

Re: [PERFORM] PostgreSQL scalability on Sun UltraSparc T1

2006-08-01 Thread Jim C. Nasby
On Sat, Jul 29, 2006 at 08:43:49AM -0700, Joshua D. Drake wrote: Jochem van Dieten wrote: Tweakers.net has done a database performance test between a Sun T2000 (8 core T1) and a Sun X4200 (2 dual core Opteron 280). The database benchmark is developed inhouse and represents the average query

Re: [PERFORM] PostgreSQL scalability on Sun UltraSparc T1

2006-08-01 Thread Arjen van der Meijden
On 1-8-2006 19:26, Jim C. Nasby wrote: On Sat, Jul 29, 2006 at 08:43:49AM -0700, Joshua D. Drake wrote: I'd love to get an english translation that we could use for PR. Actually, we have an english version of the Socket F follow-up. http://tweakers.net/reviews/638 which basically displays

[PERFORM] How to speed up this translation query?

2006-08-01 Thread tlm
I need some expert advice on how to optimize a translation query (this word choice will become clear shortly, I hope). Say I have aHUMONGOUS table of foreign language translations (call it TRANS) with records like these: meaning_id: 1 language_id: 5 translation: jidoosha meaning_id: 1

Re: [PERFORM] How to speed up this translation query?

2006-08-01 Thread Niklas Johansson
On 1 aug 2006, at 20.09, tlm wrote: SELECT q3.translation, q2.otherstuff FROM ( SELECT INPUT.word, q1.meaning_id, INPUT.otherstuff FROM INPUT INNER JOIN ( SELECT translation, meaning_id FROM TRANS WHERE translation IN (SELECT word FROM INPUT) ) AS q1 ON INPUT.word =

[PERFORM] XFS filessystem for Datawarehousing

2006-08-01 Thread Milen Kulev
I intend to test Postgres/Bizgres for DWH use. I want to use XFS filesystem to get the best possible performance at FS level(correct me if I am wrong !). Is anyone using XFS for storing/retrieving relatively large amount of data (~ 200GB)? If yes, what about the performance and stability of

FW: [PERFORM] XFS filessystem for Datawarehousing -2

2006-08-01 Thread Milen Kulev
Sorry, forgot to ask: What is the recommended/best PG block size for DWH database? 16k, 32k, 64k ? What hsould be the relation between XFS/RAID stripe size and PG block size ? Best Regards. Milen Kulev -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf

Re: [PERFORM] XFS filessystem for Datawarehousing

2006-08-01 Thread Milen Kulev
Hi Andrew, Thank you for your prompt reply. Are you using some special XFS options ? I mean special values for logbuffers bufferiosize , extent size preallocations etc ? I will have only 6 big tables and about 20 other relatively small (fact aggregation) tables (~ 10-20 GB each). I believe

Re: [PERFORM] sub select performance due to seq scans

2006-08-01 Thread H Hale
Not sure if this helps solve the problem but... (see below) As new records are added Indexes are used for awhile and then at some point postgres switches to seq scan. It is repeatable. Any suggestions/comments to try and solve this are welcome. Thanks Data is as follows:

Re: [PERFORM] XFS filessystem for Datawarehousing

2006-08-01 Thread J. Andrew Rogers
On Aug 1, 2006, at 2:49 PM, Milen Kulev wrote: Is anyone using XFS for storing/retrieving relatively large amount of data (~ 200GB)? Yes, we've been using it on Linux since v2.4 (currently v2.6) and it has been rock solid on our database servers (Opterons, running in both 32-bit and

Re: [PERFORM] XFS filessystem for Datawarehousing

2006-08-01 Thread Alvaro Herrera
J. Andrew Rogers wrote: On Aug 1, 2006, at 2:49 PM, Milen Kulev wrote: Is anyone using XFS for storing/retrieving relatively large amount of data (~ 200GB)? Yes, we've been using it on Linux since v2.4 (currently v2.6) and it has been rock solid on our database servers (Opterons,

Re: [PERFORM] PITR performance overhead?

2006-08-01 Thread Merlin Moncure
On 8/1/06, George Pavlov [EMAIL PROTECTED] wrote: I am looking for some general guidelines on what is the performance overhead of enabling point-in-time recovery (archive_command config) on an 8.1 database. Obviously it will depend on a multitude of factors, but some broad-brush statements

Re: [PERFORM] XFS filessystem for Datawarehousing

2006-08-01 Thread Mark Kirkwood
Milen Kulev wrote: Is anyone using XFS for storing/retrieving relatively large amount of data (~ 200GB)? Yes, but not for that large - only about 40-50 GB of database data. If yes, what about the performance and stability of XFS. I'm pretty happy with the performance, particularly

Re: [PERFORM] XFS filessystem for Datawarehousing -2

2006-08-01 Thread Luke Lonergan
Milen, On 8/1/06 3:19 PM, Milen Kulev [EMAIL PROTECTED] wrote: Sorry, forgot to ask: What is the recommended/best PG block size for DWH database? 16k, 32k, 64k ? What hsould be the relation between XFS/RAID stripe size and PG block size ? We have found that the page size in PG starts to

Re: [PERFORM] Query/database optimization

2006-08-01 Thread Tom Lane
Eugeny N Dzhurinsky [EMAIL PROTECTED] writes: [slow query] The bulk of your time seems to be going into this indexscan: - Index Scan using task_scheduler_icustomer_id on task_scheduler ts (cost=2.03..11.51 rows=1 width=51) (actual time=2.785..2.785 rows=0