Skip site navigation (1) Skip section navigation (2)

Re: Select performance vs. mssql

From: mark durrant <markd89(at)yahoo(dot)com>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Select performance vs. mssql
Date: 2005-05-24 19:13:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
I'm far from an expert, so this may be off-base... but
perhaps a suggestion would be to allow a hint to be
sent to the optimizer if the user doesn't care that
the result is "approximate" maybe then this wouldn't
require adding more overhead to the indexes.

MSSQL has something like this with (nolock) 
i.e. select count(*) from customers (nolock) where
name like 'Mark%' 

Regardless, I'm very impressed with PostgreSQL and I
think we're moving ahead with it.


--- Bruno Wolff III <bruno(at)wolff(dot)to> wrote:
> On Tue, May 24, 2005 at 08:36:36 -0700,
>   mark durrant <markd89(at)yahoo(dot)com> wrote:
> > 
> > --MSSQL's ability to hit the index only and not
> having
> > to go to the table itself results in a _big_
> > performance/efficiency gain. If someone who's in
> > development wants to pass this along, it would be
> a
> > nice addition to PostgreSQL sometime in the
> future.
> > I'd suspect that as well as making one query
> faster,
> > it would make everything else faster/more scalable
> as
> > the server load is so much less.
> This gets brought up a lot. The problem is that the
> index doesn't include
> information about whether the current transaction
> can see the referenced
> row. Putting this information in the index will add
> significant overhead
> to every update and the opinion of the developers is
> that this would be
> a net loss overall.

Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site


pgsql-performance by date

Next:From: PFCDate: 2005-05-24 21:17:46
Subject: Re: Need help to decide Mysql vs Postgres
Previous:From: Josh BerkusDate: 2005-05-24 18:17:32
Subject: Re: Need help to decide Mysql vs Postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group