Re: [HACKERS] enhanced pgbench
Tatsuo Ishii [EMAIL PROTECTED] writes: I think the enhanced pgbench is quite usefull and I would like to include in 8.1. Or should I keep it for 8.2? Well, we've traditionally been laxer about contrib than the core software, so the fact that we're past feature freeze isn't sufficient reason to say no. I'm inclined to say yes because I think this might make a handy debugging tool --- for instance, Janning Vygen's current problem with temp tables might be reproducible using a pgbench script, without having to write any new software. Have you thought about ripping out all the original pgbench code and instead having a default script that duplicates the original behavior? Also it seems like it'd be useful if there could be more than one script, so as to test situations where the clients aren't all doing exactly the same thing. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] enhanced pgbench
Tatsuo Ishii [EMAIL PROTECTED] writes: I think the enhanced pgbench is quite usefull and I would like to include in 8.1. Or should I keep it for 8.2? Well, we've traditionally been laxer about contrib than the core software, so the fact that we're past feature freeze isn't sufficient reason to say no. I'm inclined to say yes because I think this might make a handy debugging tool --- for instance, Janning Vygen's current problem with temp tables might be reproducible using a pgbench script, without having to write any new software. Ok. I will commit patches and will continue to work on below. Have you thought about ripping out all the original pgbench code and instead having a default script that duplicates the original behavior? No, but seems an idea. There are few things I need to think about: 1) There are three pgbench's default behaviors: TPC-B like(default), -N and -S. So we need three scripts. 2) it requires a location where those scripts reside. $prefix/etc seems appropriate? Also it seems like it'd be useful if there could be more than one script, so as to test situations where the clients aren't all doing exactly the same thing. How do you assign different scripts to different clients? -- SRA OSS, Inc. Japan Tatsuo Ishii ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] enhanced pgbench
Tatsuo Ishii [EMAIL PROTECTED] writes: 2) it requires a location where those scripts reside. $prefix/etc seems appropriate? I was thinking of just embedding the default scripts as constants in the program text. A little bit ugly but saves a lot of headache with needing to find installed files. Also it seems like it'd be useful if there could be more than one script, so as to test situations where the clients aren't all doing exactly the same thing. How do you assign different scripts to different clients? I'd be happy with either round-robin or random selection of a new script each time a thread finishes a script. regards, tom lane ---(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: [HACKERS] enhanced pgbench
Tatsuo Ishii [EMAIL PROTECTED] writes: 2) it requires a location where those scripts reside. $prefix/etc seems appropriate? I was thinking of just embedding the default scripts as constants in the program text. A little bit ugly but saves a lot of headache with needing to find installed files. I see. Also it seems like it'd be useful if there could be more than one script, so as to test situations where the clients aren't all doing exactly the same thing. How do you assign different scripts to different clients? I'd be happy with either round-robin or random selection of a new script each time a thread finishes a script. Ok. -- SRA OSS, Inc. Japan Tatsuo Ishii ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
