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 hardwar

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 ther

[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, ts.task_id,get_available_p

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 b

[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 a

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 statemen

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 qu

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 the

[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 a HUMONGOUS table of foreign language "translations" (call it TRANS) with records like these:   meaning_id: 1 language_id: 5 translation: jidoosha   meaning_id: 1 la

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 = q1.

[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 it

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: capsa.flatommemberre

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 64-

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 (Op

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 and/

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 read

Re: [PERFORM] XFS filessystem for Datawarehousing

2006-08-01 Thread Luke Lonergan
Milen, On 8/1/06 2:49 PM, "Milen Kulev" <[EMAIL PROTECTED]> wrote: > Is anyone using XFS for storing/retrieving relatively large amount of data (~ > 200GB)? I concur with the previous poster's experiences with one additional observation: We have had instabilities with XFS with software RAID (m

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 st

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