Re: [PERFORM] PostgreSQL publishes first real benchmark
Hi, I think this result will be useful for performance discussions of postgresql against other databases. http://www.spec.org/jAppServer2004/results/res2007q3/ More on Josh Berkus's blog: http://blogs.ittoolbox.com/database/soup/archives/postgresql- publishes-first-real-benchmark-17470 Congrats to everyone that worked to make this happen. While I will never get customers to buy that nice hardware (and I would recommend the JBoss Appserver anyway :-), it really is a big sign telling yes postgres can be really fast - as oposed to the urban legends around. Heiko -- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PERFORM] how small to split a table?
My question is how small to make each inherited piece? If I do modulo 10, then each sub-table will be between 32 and 34 million rows today based on current distribution. You might try this with various sizes. I did some testing lateley and found out that insert performance - even if only inserting into one partition through the master table abould halfed the speed with 4 partitions and made a 50% increase for 2 partitions. Please note: this is not representative in any kind! So while it might be cool in your case to have e.g. one partition per month, this might slow inserts down too much, so that a different number of partitions could be better. The same applies for queries as well (here perhaps in the other direction). -- Heiko W.Rupp [EMAIL PROTECTED], http://www.dpunkt.de/buch/3-89864-429-4.html ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] Auto Vacuum Problem
Hi, How do I make the physical size of the DB smaller without doing a full vacuum. This might turn out to be counterproductive, as subsequent inserts and updates will increase the size of the physical database again, which might be expensive depending on the underlying OS. -- Heiko W.Rupp [EMAIL PROTECTED], http://www.dpunkt.de/buch/3-89864-429-4.html ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PERFORM] slow result
Am 23.01.2007 um 11:34 schrieb Laurent Manchon: Hi, I have a slow response of my PostgreSQL database 7.4 using this query below on a table with 80 rows: select count(*)from tbl; count(*) is doing a full tablescan over all your 80 rows. This is a well known feature of postgres :-/ So enhancing the performance is currently only possible by having faster disk drives. -- Heiko W.Rupp [EMAIL PROTECTED], http://www.dpunkt.de/buch/ 3-89864-429-4.html ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
