[PERFORM] Pgsql (and mysql) benchmark on T2000/Solaris and some profiling

2006-05-16 Thread Arjen van der Meijden
Hi List, In the past few weeks we have been developing a read-heavy mysql-benchmark to have an alternative take at cpu/platform-performance. Not really to have a look at how fast mysql can be. This benchmark runs on mysql 4.1.x, 5.0.x and 5.1.x and is modelled after our website's production

Re: [PERFORM] IMMUTABLE?

2006-05-16 Thread Joachim Wieland
On Tue, May 16, 2006 at 12:31:41AM -0400, Tom Lane wrote: It's true that the system *could* memoize (or in our more usual parlance, cache function values) given the assumptions embodied in IMMUTABLE. But we don't, and I don't see any statement in the docs that promises that we do. For 99% of

Re: [PERFORM] Pgsql (and mysql) benchmark on T2000/Solaris and some profiling

2006-05-16 Thread Qingqing Zhou
Arjen van der Meijden [EMAIL PROTECTED] wrote Long story short, we think the test is a nice example of the relatively lightweight, read-heavy webapplications out there and therefore decided to have a go at postgresql as well. Some sort of web query behavior is quite optimized in MySQL. For

Re: [PERFORM] Pgsql (and mysql) benchmark on T2000/Solaris and some

2006-05-16 Thread Arjen van der Meijden
Qingqing Zhou wrote: Arjen van der Meijden [EMAIL PROTECTED] wrote Some sort of web query behavior is quite optimized in MySQL. For example, the query below is runing very fast due to the query result cache implementation in MySQL. Loop N times SELECT * FROM A WHERE i = 1; End loop. Yeah,

Re: [PERFORM] Pgsql (and mysql) benchmark on T2000/Solaris and some

2006-05-16 Thread Jignesh K. Shah
Hi Arjen, Looking at your outputs...of syscall and usrcall it looks like * Spending too much time in semsys which means you have too many connections and they are contending to get a lock.. which is potentially the WAL log lock * llseek is high which means you can obviously gain a bit

Re: [PERFORM] IMMUTABLE?

2006-05-16 Thread Tom Lane
Joachim Wieland [EMAIL PROTECTED] writes: So irrespective of caching to prevent evaluation across statements, within a single statement, is there a strong reason why for example in WHERE col = f(const) with f() declared as immutable or stable and without an index on col, f() still gets called

Re: [PERFORM] Pgsql (and mysql) benchmark on T2000/Solaris and some

2006-05-16 Thread Arjen van der Meijden
Hi Jignesh, Jignesh K. Shah wrote: Hi Arjen, Looking at your outputs...of syscall and usrcall it looks like * Spending too much time in semsys which means you have too many connections and they are contending to get a lock.. which is potentially the WAL log lock * llseek is high

Re: [PERFORM] Pgsql (and mysql) benchmark on T2000/Solaris and some

2006-05-16 Thread Jignesh K. Shah
Hi Arjen, Can you send me my colleagues's names in a private email? One of the drawbacks of the syscall.d script is relative timings and hence if system CPU usage is very low, it gives the relative weightage about what portion in that low is associated with what call.. So even if you have

Re: [PERFORM] IMMUTABLE?

2006-05-16 Thread Joachim Wieland
On Tue, May 16, 2006 at 09:33:14AM -0400, Tom Lane wrote: Joachim Wieland [EMAIL PROTECTED] writes: So irrespective of caching to prevent evaluation across statements, within a single statement, is there a strong reason why for example in WHERE col = f(const) with f() declared as immutable

Re: [PERFORM] IMMUTABLE?

2006-05-16 Thread David Wheeler
On May 15, 2006, at 21:31, Tom Lane wrote: Sure. As I read it, that's talking about a static transformation: planner sees 2 + 2 (or if you prefer, int4pl(2,2)), planner runs the function and replaces the expression with 4. Nothing there about memoization. Oh, I see. So it's more like a

Re: [PERFORM] Pgsql (and mysql) benchmark on T2000/Solaris and some

2006-05-16 Thread Arjen van der Meijden
Hi Jignesh, The settings from that 'special T2000 dvd' differed from the recommended settings on the website you provided. But I don't see much difference in performance with any of the adjustments, it appears to be more or less the same. Here are a few iostat lines by the way: sd0

[PERFORM] Adding and filling new column on big table

2006-05-16 Thread Jonathan Blitz
I have a table of about 500,000 rows. I need to add a new column and populate it. So, I have tried to run the following command. The command never finishes (I gave up after about and hour and a half!). Note that none of the columns have indexes. Update mytable set new_column =

Re: [PERFORM] Speed Up Offset and Limit Clause

2006-05-16 Thread Christian Paul Cosinas
I am creating an application that gets the value of a large table and write it to a file. Why I want to use offset and limit is for me to create a threaded application so that they will not get the same results. For example: Thread 1 : gets offset 0 limit 5000 Thread 2 : gets offset 5000 limit

Re: [PERFORM] IMMUTABLE?

2006-05-16 Thread David Wheeler
On May 16, 2006, at 18:29, Christopher Kings-Lynne wrote: Yes, but there are definitely programming cases where memoization/ caching definitely helps. And it's easy to tell for a given function whether or not it really helps by simply trying it with CACHED and without. Would this be a

Re: [PERFORM] Speed Up Offset and Limit Clause

2006-05-16 Thread Craig A. James
Christian Paul Cosinas wrote: I am creating an application that gets the value of a large table and write it to a file. Why I want to use offset and limit is for me to create a threaded application so that they will not get the same results. For example: Thread 1 : gets offset 0 limit 5000

Re: [PERFORM] Adding and filling new column on big table

2006-05-16 Thread Michael Fuhr
On Wed, May 17, 2006 at 03:19:26AM +0200, Jonathan Blitz wrote: I have a table of about 500,000 rows. I need to add a new column and populate it. So, I have tried to run the following command. The command never finishes (I gave up after about and hour and a half!). If you install