Re: [PERFORM] Performance pb vs SQLServer.

2005-08-18 Thread Stéphane COEZ
> > One little thing. Did you shutdown sql2000 while testing > postgresql? Remember that postgresql uses system cache. > Sql2000 uses a large part of memory as buffer and it will not > be available to operating system. I must say that, probably, > results will be the same, but it will be a b

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-18 Thread Stéphane COEZ
> De : Magnus Hagander [mailto:[EMAIL PROTECTED] > Out of curiosity, what plan do you get from SQLServer? I bet > it's a clustered index scan... > > > //Magnus > I have a Table scan and Hashaggregate... Stephane ---(end of broadcast)--- TI

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-18 Thread Stéphane COEZ
John Arbash Meinel wrote : > > You might also try a different query, something like: > > SELECT DISTINCT cod FROM mytable ORDER BY cod GROUP BY cod; > (You may or may not want order by, or group by, try the different > combinations.) > It might be possible to have the planner realize that all y

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-18 Thread John A Meinel
Qingqing Zhou wrote: > "Alvaro Herrera" <[EMAIL PROTECTED]> writes > >>Interesting; do they use an overwriting storage manager like Oracle, or >>a non-overwriting one like Postgres? >> > > > They call this MVCC "RLV(row level versioning)". I think they use rollback > segment like Oracle (a.k.a "ver

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-18 Thread Qingqing Zhou
"Alvaro Herrera" <[EMAIL PROTECTED]> writes > > Interesting; do they use an overwriting storage manager like Oracle, or > a non-overwriting one like Postgres? > They call this MVCC "RLV(row level versioning)". I think they use rollback segment like Oracle (a.k.a "version store" or tempdb in SQL S

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-15 Thread Alvaro Herrera
On Mon, Aug 15, 2005 at 10:25:47AM +0200, Magnus Hagander wrote: > SQL 2005 has "MVCC" (they call it something different, of course, but > that's basicallyi what it is) Interesting; do they use an overwriting storage manager like Oracle, or a non-overwriting one like Postgres? -- Alvaro Herrera

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-15 Thread Magnus Hagander
> Hi, > > I have a perfomance issue : > > I run PG (8.0.3) and SQLServer2000 on a Windows2000 Server > (P4 1,5Ghz 512Mo) I have a table (320 rows) and I run > this single query : > > select cod from mytable group by cod > I have an index on cod (char(4) - 88 different values) > > PG = ~ 2

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-15 Thread Magnus Hagander
> ["very, very offtopic"] > Ok. This comparition is just as useless as the other one, > because it's comparing oranges with apples (It's funny > anyway). I was just choosing an example in which you can see > the best of postgresql against 'not so nice' behavior of > mssql2000 (no service pack,

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-14 Thread dario_d_s
One little thing. Did you shutdown sql2000 while testing postgresql? Remember that postgresql uses system cache. Sql2000 uses a large part of memory as buffer and it will not be available to operating system. I must say that, probably, results will be the same, but it will be a better test. > I

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-14 Thread Steinar H. Gunderson
On Sun, Aug 14, 2005 at 09:18:45PM -0400, Tom Lane wrote: > Not really. There's been some speculation about implementing index > "skip search" --- once you've verified there's at least one visible > row of a given index value, tell the index to skip to the next different > value instead of handing

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-14 Thread Tom Lane
"Steinar H. Gunderson" <[EMAIL PROTECTED]> writes: > To me, it looks like he'll get 88 rows, not 3.2M. Surely we must be able to > do something better than a full sequential scan in this case? Not really. There's been some speculation about implementing index "skip search" --- once you've verifie

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-14 Thread John Arbash Meinel
Steinar H. Gunderson wrote: >On Sun, Aug 14, 2005 at 07:27:38PM -0500, John Arbash Meinel wrote: > > >>My guess is that this is part of a larger query. There isn't really much >>you can do. If you want all 3.2M rows, then you have to wait for them to >>be pulled in. >> >> > >To me, it looks

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-14 Thread Steinar H. Gunderson
On Sun, Aug 14, 2005 at 07:27:38PM -0500, John Arbash Meinel wrote: > If you are just trying to determine what the unique entries are for cod, > you probably are better off doing some normalization, and keeping a > separate table of cod values. Pah, I missed this part of the e-mail -- you can igno

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-14 Thread Steinar H. Gunderson
On Sun, Aug 14, 2005 at 07:27:38PM -0500, John Arbash Meinel wrote: > My guess is that this is part of a larger query. There isn't really much > you can do. If you want all 3.2M rows, then you have to wait for them to > be pulled in. To me, it looks like he'll get 88 rows, not 3.2M. Surely we must

Re: [PERFORM] Performance pb vs SQLServer.

2005-08-14 Thread John Arbash Meinel
Stéphane COEZ wrote: >Hi, > >I have a perfomance issue : > >I run PG (8.0.3) and SQLServer2000 on a Windows2000 Server (P4 1,5Ghz 512Mo) >I have a table (320 rows) and I run this single query : > >select cod from mytable group by cod >I have an index on cod (char(4) - 88 different values) > >P