[PERFORM] Configuring System for Speed
I am in the process of speccing out a new box for a highly utilized (updates, inserts, selects) 40GB+ database. I'm trying to maximize performance on a budget, and I would appreciate any feedback on any of the following. Hardware: 2 - Intel Xeon 5160 3.0 GHz 4MB 1333MHz 8 - Kingston 4GB DDR2 ECC Fully Buffered 16 - WD Raptor 150GB 1 RPM SATA II HD 1 - 3Ware 9550SX-16ML Serial ATA II RAID card 1 - Supermicro X7DBE+ Motherboard 1 - Supermicro SC836TQ-R800V Case The Woodcrest CPU, Raptor HD and 3Ware 9550SX RAID card have all been highly recommended on this list, so there may not be much to comment on there. The Supermicro X7DBE+ motherboard is appealing because of its 16 RAM slots and 64GB of maximum memory. The Supermicro SC836TQ- R800 case was selected because of its 16 drive bays in 3U and dual 800W power supplies (the motherboard requires 700W). RAID Configuration/File System: A lot of info in the lists, but I'm not sure of the best approach for this setup. I was thinking of using 14 drives in a RAID 10 (ext3) for the db and wals and 2 mirrored drives (ext3 or xfs) for the OS. Another option would be 12 drives in a RAID 10 for the database (ext3, maybe ext2) and 4 drives in a RAID 10 for the OS and wals (ext3) (with separate RAID cards). There are many choices here. Any suggestions? OS: The consensus in the list seems to be as long as you have the 2.6 Linux Kernel, it's really a matter of personal preference. However, it's hard to have a preference when you're new to the Linux world, like I am. Red Hat, Fedora Core, Slackware, Suse, Gentoo? I guess my primary goal is speed, stability, and ease of use. Any advice here, no matter how minimal, would be appreciated. Thanks, Brian Wipf ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PERFORM] Configuring System for Speed
Brian, I like all of the HW - I just thoroughly reviewed this and came to the same HW choices you did. The new SuperMicro chassis is an improvement on one we have used for 21 servers like this. One modification: we implemented two internal 60GB laptop hard drives with an additional 3Ware 8006-2LP controller on each machine for the OS. This frees up all 16 SATA II drives for data. The laptop drives are super stable and reliable under high heat conditions and they are small, so having them inside the case is no big deal. BTW - we had ASAcomputers.com make our systems for us and they did a good job. We use CentOS 4 on our lab systems and it works fine. I recommend XFS for the DBMS data drives, along with RAID10 on the 3Ware controllers. With normal Postgres you shouldn't expect to get more than about 350MB/s on those CPUs for a single query, but with increased user count, the RAID10 should scale fine to about 1200MB/s sequential transfer using XFS and a lot slower with ext3. - Luke On 9/8/06 12:52 AM, "Brian Wipf" <[EMAIL PROTECTED]> wrote: > I am in the process of speccing out a new box for a highly utilized > (updates, inserts, selects) 40GB+ database. I'm trying to maximize > performance on a budget, and I would appreciate any feedback on any > of the following. > > Hardware: > 2 - Intel Xeon 5160 3.0 GHz 4MB 1333MHz > 8 - Kingston 4GB DDR2 ECC Fully Buffered > 16 - WD Raptor 150GB 1 RPM SATA II HD > 1 - 3Ware 9550SX-16ML Serial ATA II RAID card > 1 - Supermicro X7DBE+ Motherboard > 1 - Supermicro SC836TQ-R800V Case > > The Woodcrest CPU, Raptor HD and 3Ware 9550SX RAID card have all been > highly recommended on this list, so there may not be much to comment > on there. The Supermicro X7DBE+ motherboard is appealing because of > its 16 RAM slots and 64GB of maximum memory. The Supermicro SC836TQ- > R800 case was selected because of its 16 drive bays in 3U and dual > 800W power supplies (the motherboard requires 700W). > > RAID Configuration/File System: > A lot of info in the lists, but I'm not sure of the best approach for > this setup. > I was thinking of using 14 drives in a RAID 10 (ext3) for the db and > wals and 2 mirrored drives (ext3 or xfs) for the OS. Another option > would be 12 drives in a RAID 10 for the database (ext3, maybe ext2) > and 4 drives in a RAID 10 for the OS and wals (ext3) (with separate > RAID cards). There are many choices here. Any suggestions? > > OS: > The consensus in the list seems to be as long as you have the 2.6 > Linux Kernel, it's really a matter of personal preference. However, > it's hard to have a preference when you're new to the Linux world, > like I am. Red Hat, Fedora Core, Slackware, Suse, Gentoo? I guess my > primary goal is speed, stability, and ease of use. Any advice here, > no matter how minimal, would be appreciated. > > Thanks, > > Brian Wipf > > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PERFORM] Performance in a 7 TB database.
Hi, I have a customer who wants a database solution for a 7 TB database. Insert will be the main action in the database. There are some case studies with detail information about performance and hardware solution on this database size? What are the minimum hardware requirements for this kind of database? Thanks is advance, Nuno DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with postgresql and some SAS raid-figures
Hi, Arjen, On 8-Sep-06, at 1:51 AM, Arjen van der Meijden wrote: Hi, We've been running our "webapp database"-benchmark again on mysql and postgresql. This time using a Fujitsu-Siemens RX300 S3 machine equipped with a 2.66Ghz Woodcrest (5150) and a 3.73Ghz Dempsey (5080). And compared those results to our earlier undertaken Opteron benchmarks on 2.4GHz' Socket F- and 940-versions (2216, 280). You can see the english translation here: http://tweakers.net/reviews/646 The Woodcrest is quite a bit faster than the Opterons. Actually... With Hyperthreading *enabled* the older Dempsey-processor is also faster than the Opterons with PostgreSQL. But then again, it is the top-model Dempsey and not a top-model Opteron so that isn't a clear win. Of course its clear that even a top-Opteron wouldn't beat the Dempsey's as easily as it would have beaten the older Xeon's before that. Why wouldn't you use a top of the line Opteron ? Again PostgreSQL shows very good scalability, so good even HyperThreading adds extra performance to it with 4 cores enabled... while MySQL in every version we tested (5.1.9 is not displayed, but showed similar performance) was slower with HT enabled. Further more we received our ordered Dell MD1000 SAS-enclosure which has 15 SAS Fujitsu MAX3036RC disks and that unit is controlled using a Dell PERC 5/e. We've done some benchmarks (unfortunately everything is in Dutch for this). We tested varying amounts of disks in RAID10 (a set of 4,5,6 and 7 2-disk-mirrors striped), RAID50 and RAID5. The interfaces to display the results are in a google-stylee beta-state, but here is a list of all benchmarks done: http://tweakers.net/benchdb/search?query=md1000&ColcomboID=5 Hover over the left titles to see how many disks and in what raid- level was done. Here is a comparison of 14 disk RAID5/50/10's: http://tweakers.net/benchdb/testcombo/wide/?TestcomboIDs%5B1156% 5D=1&TestcomboIDs%5B1178%5D=1&TestcomboIDs%5B1176% 5D=1&DB=Nieuws&Query=Keyword For raid5 we have some graphs: http://tweakers.net/benchdb/testcombo/1156 Scroll down to see how adding disks improves performance on it. The Areca 1280 with WD Raptor's is a very good alternative (or even better) as you can see for most benchmarks, but is beaten as soon as the relative weight of random-IO increases (I/O-meter fileserver and database benchmarks), the processor on the 1280 is faster than the one on the Dell-controller so its faster in sequential IO. These benchmarks were not done using postgresql, so you shouldn't read them as absolute for all your situations ;-) But you can get a good impression I think. Best regards, Arjen van der Meijden Tweakers.net ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
Dave Cramer wrote: Hi, Arjen, The Woodcrest is quite a bit faster than the Opterons. Actually... With Hyperthreading *enabled* the older Dempsey-processor is also faster than the Opterons with PostgreSQL. But then again, it is the top-model Dempsey and not a top-model Opteron so that isn't a clear win. Of course its clear that even a top-Opteron wouldn't beat the Dempsey's as easily as it would have beaten the older Xeon's before that. Why wouldn't you use a top of the line Opteron ? What do you mean by this question? Why we didn't test the Opteron 285 instead of the 280? Well, its not that you can just go up to a hardware supplier and pick exactly the system you want to review/benchmar... especially not with pre-production hardware that (at the time) wasn't very widely available. Normally, you just get what system they have available at their marketing or pre-sales department. The Opteron 280 was from an earlier review and was fitted in the "Try and Buy"-version of the Sun Fire x4200. In that system; you only have a few options where the 280 was the fastest at the time. But then again, systems with the Woodcrest 5150 (the subtop one) and Opteron 280 (also the subtop one) are about equal in price, so its not a bad comparison in a bang-for-bucks point of view. The Dempsey was added to show how both the Opteron and the newer Woodcrest would compete against that one. Best regards, Arjen ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PERFORM] Performance problem with joins
Hi
i have a severe performance problem with one of my
views which has 6 to 8 joins .. any help will be
appreciated..
the view is:
CREATE OR REPLACE VIEW thsn.trade_view AS
SELECT tra.tra_id, tra.per_id, tra.fir_id,
tra.tra_dcn, tra.tra_startdate::date AS tra_startdate,
tra.tra_enddate::date AS tra_enddate,
tra.tra_highprice, tra.tra_lowprice, tra.tra_shares,
tra.tra_marketvalue, tra.tra_commonsharesheld,
tra.tra_directsharesheld, tra.tra_indirectsharesheld,
tra.fun_id, tra.tra_amended, tra.tra_ownership,
tra.tra_touchdate::date AS tra_touchdate,
tra.tra_cdate, tra.tra_udate, tra.tra_relevant,
tra.tra_type, tra.tra_date::date AS tra_date,
per.per_fullname, fir.fir_name, fir.bra_id,
cac90.pc_perf AS tra_performance90, incac90.pc_perf AS
tra_indexperformance90, cac180.pc_perf AS
tra_performance180, incac180.pc_perf AS
tra_indexperformance180, cac270.pc_perf AS
tra_performance270, incac270.pc_perf AS
tra_indexperformance270, kurl.kur_marketcap AS
tra_marketkap, kurl.kur_close AS tra_close,
thsn.per_letztebewertungkauf(per.per_id, fir.fir_id)
AS per_punktekauf,
thsn.per_letztebewertungverkauf(per.per_id,
fir.fir_id) AS per_punkteverkauf, fun.fun_thid,
fun.fun_name, wp.wp_symbol
FROM thsn.trade tra
JOIN thsn.person per ON tra.per_id = per.per_id
JOIN thsn.firma fir ON tra.fir_id = fir.fir_id
LEFT JOIN thsn.kurs_latest kurl ON ('U'::text ||
fir.fir_cusip::text) =kurl.fir_cusip
LEFT JOIN thsn.perfcache90 cac90 ON tra.tra_id =
cac90.tra_id
LEFT JOIN thsn.indexperfcache90 incac90 ON tra.tra_id
= incac90.tra_id
LEFT JOIN thsn.perfcache180 cac180 ON tra.tra_id =
cac180.tra_id
LEFT JOIN thsn.indexperfcache180 incac180 ON
tra.tra_id = incac180.tra_id
LEFT JOIN thsn.perfcache270 cac270 ON tra.tra_id =
cac270.tra_id
LEFT JOIN thsn.indexperfcache270 incac270 ON
tra.tra_id = incac270.tra_id
LEFT JOIN thsn.funktion fun ON tra.fun_id = fun.fun_id
LEFT JOIN thsn.wertpapier wp ON fir.wp_id = wp.wp_id;
and now if i query this view with this explain query :
explain select * from thsn.trade_view tra where
tra_date>'2006-05-29'
the output:
"Merge Right Join (cost=304605.98..319519.02
rows=324367 width=370)"
" Merge Cond: ("outer".wp_id = "inner".wp_id)"
" -> Index Scan using pk_wertpapier on wertpapier wp
(cost=0.00..1134.06 rows=30651 width=12)"
" -> Sort (cost=304605.98..305416.90 rows=324367
width=370)"
" Sort Key: fir.wp_id"
" -> Hash Left Join (cost=102943.82..274914.62
rows=324367 width=370)"
" Hash Cond: ("outer".fun_id = "inner".fun_id)"
" -> Hash Left Join (cost=102942.07..271019.38
rows=324367 width=340)"
" Hash Cond: ("outer".tra_id = "inner".tra_id)"
" -> Hash Left Join (cost=71679.05..216585.25
rows=324367 width=308)"
" Hash Cond: ("outer".tra_id = "inner".tra_id)"
" -> Hash Left Join (cost=53148.50..189791.47
rows=324367 width=297)"
" Hash Cond: ("outer".tra_id = "inner".tra_id)"
" -> Hash Left Join (cost=25994.49..148209.39
rows=324367 width=275)"
" Hash Cond: (('U'::text || ("outer".fir_cusip)::text)
= ("inner".fir_cusip)::text)"
" -> Hash Join (cost=24702.75..133134.22 rows=324367
width=264)"
" Hash Cond: ("outer".per_id = "inner".per_id)"
" -> Hash Join (cost=1450.91..99340.45 rows=324367
width=237)"
" Hash Cond: ("outer".fir_id = "inner".fir_id)"
" -> Seq Scan on trade tra (cost=0.00..88158.53
rows=324367 width=181)"
" Filter: ((tra_date)::date > '2006-05-29'::date)"
"-> Hash (cost=1374.53..1374.53 rows=30553 width=56)"
"-> Seq Scan on firma fir (cost=0.00..1374.53
rows=30553 width=56)"
"-> Hash (cost=22629.87..22629.87 rows=248787
width=27)"
"-> Seq Scan on person per (cost=0.00..22629.87
rows=248787 width=27)"
"-> Hash (cost=1232.59..1232.59 rows=23659 width=35)"
"-> Seq Scan on kurs_latest kurl (cost=0.00..1232.59
rows=23659 width=35)"
"-> Hash (cost=17244.44..17244.44 rows=814044
width=19)"
"-> Seq Scan on perfcache90 cac90 (cost=0.00..17244.44
rows=814044 width=19)"
" -> Hash (cost=6994.97..6994.97 rows=351797
width=19)"
" -> Seq Scan on indexperfcache90 incac90
(cost=0.00..6994.97 rows=351797 width=19)"
" -> Hash (cost=16590.44..16590.44 rows=776044
width=19)"
" -> Seq Scan on perfcache180 cac180
(cost=0.00..16590.44 rows=776044 width=19)"
" -> Hash (cost=6704.00..6704.00 rows=336800
width=18)"
" -> Seq Scan on indexperfcache180 incac180
(cost=0.00..6704.00 rows=336800 width=18)"
" -> Hash (cost=14755.09..14755.09 rows=695309
width=19)"
" -> Seq Scan on perfcache270 cac270
(cost=0.00..14755.09 rows=695309 width=19)"
" -> Hash (cost=6413.93..6413.93 rows=323893
width=19)"
" -> Seq Scan on indexperfcache270 incac270
(cost=0.00..6413.93 rows=323893 width=19)"
" -> Hash (cost=1.60..1.60 rows=60 width=34)"
" -> Seq Scan on funktion fun (cost=0.00..1.60 rows=60
width=34)"
and without the joins if i run a explain on this
query:
EXPLAIN SELECT tra.tra_id, tra.per_id, tra.fir_id,
tra.tra_dcn, tra.tra_startdate::date AS tra_startdate,
tra.tra_enddate::date AS tra_enddate,
tra.tra_highprice, tra.tra_lowprice, tra.tra_shares,
tra.tra_marketvalue, tra.tra_commonsharesheld,
tra.tra_directsharesheld, tra.tra
Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with postgresql and some SAS raid-figures
On 8-Sep-06, at 8:44 AM, Arjen van der Meijden wrote: Dave Cramer wrote: Hi, Arjen, The Woodcrest is quite a bit faster than the Opterons. Actually... With Hyperthreading *enabled* the older Dempsey- processor is also faster than the Opterons with PostgreSQL. But then again, it is the top-model Dempsey and not a top-model Opteron so that isn't a clear win. Of course its clear that even a top-Opteron wouldn't beat the Dempsey's as easily as it would have beaten the older Xeon's before that. Why wouldn't you use a top of the line Opteron ? What do you mean by this question? Why we didn't test the Opteron 285 instead of the 280? Yes, that is the question. Well, its not that you can just go up to a hardware supplier and pick exactly the system you want to review/benchmar... especially not with pre-production hardware that (at the time) wasn't very widely available. Normally, you just get what system they have available at their marketing or pre-sales department. Understandable. The Opteron 280 was from an earlier review and was fitted in the "Try and Buy"-version of the Sun Fire x4200. In that system; you only have a few options where the 280 was the fastest at the time. But then again, systems with the Woodcrest 5150 (the subtop one) and Opteron 280 (also the subtop one) are about equal in price, so its not a bad comparison in a bang-for-bucks point of view. The Dempsey was added to show how both the Opteron and the newer Woodcrest would compete against that one. Did I read this correctly that one of the Opterons in the test only had 4G of ram vs 7 G in the Intel boxes ? If so this is a severely limiting factor for postgresql at least? Dave Best regards, Arjen ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] Configuring System for Speed
Brian Wipf wrote: I am in the process of speccing out a new box for a highly utilized (updates, inserts, selects) 40GB+ database. I'm trying to maximize performance on a budget, and I would appreciate any feedback on any of the following. Perhaps this is off topic, but here is bit from my experience. Using single server for both read (select) and write (insert, update, delete) operations is the way to slow things down. Consider to split query workload into OLTP and OLAP queries . Set up Slony replication and use slave server for read operations only . Buy 1 cheap box (slave) and another more expensive one for master. Keep in mind that DB schema optimization for particular query workload is essential . You just can not get good performance for selects if schema is optimized for inserts and vice versa. OS: The consensus in the list seems to be as long as you have the 2.6 Linux Kernel, it's really a matter of personal preference. However, it's hard to have a preference when you're new to the Linux world, like I am. Red Hat, Fedora Core, Slackware, Suse, Gentoo? I guess my primary goal is speed, stability, and ease of use. Any advice here, no matter how minimal, would be appreciated. My answer is FreeBSD6.1. Thanks, Brian Wipf ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Best Regards, Alvis ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] Performance problem with joins
fardeen memon <[EMAIL PROTECTED]> writes: > What is it that i am doing wrong? I think the forced coercion to date type in the view case is preventing the planner from making a good guess about the selectivity of the condition on tra_date. It has stats about tra_date's distribution, but none about the distribution of "tra_date::date". regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PERFORM] unsubscribe me
hi plz unsubscribe me.. i am sending mail to this id.. for unsubscribing.. is it correct.. my mail box is gettin flooded..
Re: [PERFORM] unsubscribe me
"Phadnis" writes: > plz unsubscribe me.. > > i am sending mail to this id.. for unsubscribing.. is it correct.. > my mail box is gettin flooded.. you managed to subscribe, you'll probably manage to unsubcribe. hint: the email headers contain the information for unsubscribing. -- Guillaume Cottenceau Create your personal SMS or WAP Service - visit http://mobilefriends.ch/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
On 8-9-2006 15:01 Dave Cramer wrote: But then again, systems with the Woodcrest 5150 (the subtop one) and Opteron 280 (also the subtop one) are about equal in price, so its not a bad comparison in a bang-for-bucks point of view. The Dempsey was added to show how both the Opteron and the newer Woodcrest would compete against that one. Did I read this correctly that one of the Opterons in the test only had 4G of ram vs 7 G in the Intel boxes ? If so this is a severely limiting factor for postgresql at least? Actually, its not in this benchmark. Its not a large enough dataset to put any pressure on IO, not even with just 2GB of memory. But, to display it more acurately have a look here: http://tweakers.net/reviews/638/2 and then scroll down to the bottom-graph. As you can see, the 8GB-version was faster, but not that much to call it 'severely'. Unfortunately, the system just wasn't very stable with that 8GB memory (it was other memory, not just more). So we couldn't finish much benchmarks with it and decided, partially based on this graph to just go for the 4GB. Anyway, you can always compare the results of the Woodcrest with the Sun Fire x4200-results (called 'Opteron DDR' or 'Opteron 940' in the latest article) to see how a Opteron with 8GB of memory compares to the Woodcrest. More of those results can be found in this english article: http://tweakers.net/reviews/638 And in this Dutch one: http://tweakers.net/reviews/633 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
Arjen van der Meijden wrote: > On 8-9-2006 15:01 Dave Cramer wrote: >> >>> But then again, systems with the Woodcrest 5150 (the subtop one) and >>> Opteron 280 (also the subtop one) are about equal in price, so its >>> not a bad comparison in a bang-for-bucks point of view. The Dempsey >>> was added to show how both the Opteron and the newer Woodcrest would >>> compete against that one. >> >> Did I read this correctly that one of the Opterons in the test only >> had 4G of ram vs 7 G in the Intel boxes ? If so this is a severely >> limiting factor for postgresql at least? > > Actually, its not in this benchmark. Its not a large enough dataset to > put any pressure on IO, not even with just 2GB of memory. interesting - so this is a mostly CPU-bound benchmark ? Out of curiousity have you done any profiling on the databases under test to see where they are spending their time ? Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] Performance in a 7 TB database.
On Fri, 2006-09-08 at 10:30 +0100, Nuno Alexandre Alves wrote: > Hi, > > I have a customer who wants a database solution for a 7 TB database. > Insert will be the main action in the database. > > There are some case studies with detail information about performance > and hardware solution on this database size? > What are the minimum hardware requirements for this kind of database? > This is a good place to start: http://www.postgresql.org/about/users I would expect that the case studies for databases greater than 7TB are few and far between (for any database software). If you decide PostgreSQL is right, I'm sure the advocacy mailing list would like to see your case study when you are finished. Your hardware requirements mostly depend on how you're going to use the data. If you expect that most of the data will never be read, and that the database will be more of an archive, the requirements might be quite reasonable. However, if or when you do need to search through that data, expect it to take a long time. Regards, Jeff Davis ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with
On 8-9-2006 18:18 Stefan Kaltenbrunner wrote: interesting - so this is a mostly CPU-bound benchmark ? Out of curiousity have you done any profiling on the databases under test to see where they are spending their time ? Yeah, it is. We didn't do any profiling. We had a Sun-engineer visit us to see why MySQL performed so bad on the T2000 and he has done some profiling, but that is of course just a small and specific part of our total set of benchmarks. Postgresql was mostly left out of that picture since it performed pretty well (although it may even do better with more tuning and profiling). We are/were not interested enough in the profiling-part, since we just run the benchmark to see how fast each system is. Not really to see how fast each database is or why a database is faster on X or Y. The latter is of course pretty interesting, but also requires quite a bit of knowledge of the internals and a bit of time to analyze the results... Best regards, Arjen ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
