Re: [PERFORM] 8rc2 & BLCKSZ

2004-12-22 Thread Mario Weilguni
Am Mittwoch, 22. Dezember 2004 22:04 schrieb Tom Lane: > Vivek Khera writes: > > One of the suggestions handed to me a long time ago for speeding up PG > > on FreeBSD was to double the default blocksize in PG. I tried it, but > > found not a significant enough speed up to make it worth the troubl

Re: [PERFORM] Why so much time difference with a same query/plan?

2004-12-22 Thread Yann Michel
Hi, On Wed, Dec 22, 2004 at 01:52:40PM -0800, Litao Wu wrote: > Does the order of columns in the index matter since > more than 50% customer_id = 158? > > I think it does not in Oracle. > > Will the performance be better if I change index > xxx_idx to ("domain", customer_id, created)? Well, in

Re: [PERFORM] Memory leak tsearch2 VACUUM FULL VERBOSE ANALYZE

2004-12-22 Thread Tom Lane
Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes: > I think I have a test case for 7.4.2 Can you send me the test data (off-list)? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] Memory leak tsearch2 VACUUM FULL VERBOSE ANALYZE

2004-12-22 Thread Pailloncy Jean-Gerard
I think I have a test case for 7.4.2 So I have a 3 millions of rows table "metadata" with a tsearch2 index. I had memory leak in "vacuum full verbose analyze" I drop the index, run "vacuum full verbose analyze", recreate the index and re-run "vacuum full verbose analyze". The I run my script to i

Re: [PERFORM] Why so much time difference with a same query/plan?

2004-12-22 Thread Litao Wu
Does the order of columns in the index matter since more than 50% customer_id = 158? I think it does not in Oracle. Will the performance be better if I change index xxx_idx to ("domain", customer_id, created)? I will test myself when possible. Thanks, --- Litao Wu <[EMAIL PROTECTED]> wrote: >

Re: [PERFORM] 8rc2 & BLCKSZ

2004-12-22 Thread Tom Lane
Vivek Khera writes: > One of the suggestions handed to me a long time ago for speeding up PG > on FreeBSD was to double the default blocksize in PG. I tried it, but > found not a significant enough speed up to make it worth the trouble > to remember to patch every version of Pg during the upgrade

Re: [PERFORM] 8rc2 & BLCKSZ

2004-12-22 Thread Vivek Khera
> "PJ" == Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes: PJ> Hi, PJ> A small test with 8rc2 and BLCKSZ of 8k and 32k. PJ> It seems there is a 10% increase in the number of transactions by PJ> second. PJ> Does someone plan to carefully test the impact of BLCKSZ ? One of the suggestions hand

[PERFORM] Why so much time difference with a same query/plan?

2004-12-22 Thread Litao Wu
Merry Xmas! I have a query. It sometimes runs OK and sometimes horrible. Here is result from explain analyze: explain analyze SELECT module, sum(c1) + sum(c2) + sum(c3) + sum(c4) + sum(c5) AS "count" FROM xxx WHERE created >= ('now'::timestamptz - '1 day'::interval) AND customer_id='158' AND

[PERFORM] 8rc2 & BLCKSZ

2004-12-22 Thread Pailloncy Jean-Gerard
Hi, A small test with 8rc2 and BLCKSZ of 8k and 32k. It seems there is a 10% increase in the number of transactions by second. Does someone plan to carefully test the impact of BLCKSZ ? Cordialement, Jean-Gérard Pailloncy with 8k: > /test/bin/pgbench -c 10 -t 300 test starting vacuum...end. trans