Re: [PERFORM] How can I make use of both CPUs in a dual processor

2005-02-10 Thread Alex
Thanks for all the suggestions. It seems that creating indices, or even import data using a copy is easy to implement. I also have some jobs that create reports and want to try if I gain anything if i work reports in parallel. will give it a try in the next week and let you know the resuls. Ale

Re: [PERFORM] Benchmark

2005-02-10 Thread Jeff
On Feb 10, 2005, at 12:49 AM, Jaime Casanova wrote: Hi guys, i'm planning try to do a comparative between some DBMS and postgresql (informix, oracle, m$ sql server, firebird and even mysql) i'm coordinating with people in the irc spanish postgresql channel. 2) point me to a good benchmark test or s

[PERFORM] Large time difference between explain analyze and normal run

2005-02-10 Thread Chris Kratz
Does anyone have any idea why there be over a 4s difference between running the statement directly and using explain analyze? Multiple runs give the same result and I've tested on several servers. db=# \timing Timing is on. db=# select count(*) from answer; count 530576 (1 row) Time

Re: [PERFORM] Large time difference between explain analyze and normal run

2005-02-10 Thread Tom Lane
Chris Kratz <[EMAIL PROTECTED]> writes: > Does anyone have any idea why there be over a 4s difference between running > the statement directly and using explain analyze? > Aggregate (cost=9848.12..9848.12 rows=1 width=0) (actual > time=4841.231..4841.235 rows=1 loops=1) >-> Seq Scan on an

Re: [PERFORM] Large time difference between explain analyze and normal run

2005-02-10 Thread Chris Kratz
On Thursday 10 February 2005 01:58 pm, Tom Lane wrote: > Chris Kratz <[EMAIL PROTECTED]> writes: > > Does anyone have any idea why there be over a 4s difference between > > running the statement directly and using explain analyze? > > > > Aggregate (cost=9848.12..9848.12 rows=1 width=0) (actual >

Re: [PERFORM] Large time difference between explain analyze and normal run

2005-02-10 Thread Darcy Buskermolen
On February 10, 2005 10:58 am, Tom Lane wrote: > Chris Kratz <[EMAIL PROTECTED]> writes: > > Does anyone have any idea why there be over a 4s difference between > > running the statement directly and using explain analyze? > > > > Aggregate (cost=9848.12..9848.12 rows=1 width=0) (actual > > time=

Re: [PERFORM] Large time difference between explain analyze and normal run

2005-02-10 Thread Chris Kratz
On Thursday 10 February 2005 03:09 pm, Darcy Buskermolen wrote: > On February 10, 2005 10:58 am, Tom Lane wrote: > > Chris Kratz <[EMAIL PROTECTED]> writes: > > > Does anyone have any idea why there be over a 4s difference between > > > running the statement directly and using explain analyze? > >

Re: [PERFORM] Benchmark

2005-02-10 Thread Mitch Pirtle
On Thu, 10 Feb 2005 08:21:09 -0500, Jeff <[EMAIL PROTECTED]> wrote: > > If you plan on making your results public be very careful with the > license agreements on the other db's. I know Oracle forbids the > release of benchmark numbers without their approval. ...as all of the other commercial da

Re: [PERFORM] Benchmark

2005-02-10 Thread Tom Lane
Mitch Pirtle <[EMAIL PROTECTED]> writes: > It would be really useful to know if anyone has ever been punished for > doing this, as IANAL but that restriction is going to be very, VERY > difficult to back up in court without precedence. Is this just a > deterrent, or is it real? If Oracle doesn't e

Re: [PERFORM] Benchmark

2005-02-10 Thread Mitch Pirtle
On Fri, 11 Feb 2005 01:38:13 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: > > If Oracle doesn't eat your rear for lunch, That would be more like an appetizer at a california cuisine place. > it would only be because you > hadn't annoyed them sufficiently for them to bother. Under the terms of >

Re: [PERFORM] Benchmark

2005-02-10 Thread Jaime Casanova
On Fri, 11 Feb 2005 01:38:13 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: > Mitch Pirtle <[EMAIL PROTECTED]> writes: > > It would be really useful to know if anyone has ever been punished for > > doing this, as IANAL but that restriction is going to be very, VERY > > difficult to back up in court wit