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

Re: [PERFORM] temporary indexes

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org,pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] temporary indexes
Date: 2006-02-28 21:02:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
On Tue, Feb 28, 2006 at 11:36:28AM -0600, Kevin Grittner wrote:
> <digression>
> I'm all for that.  So far, we've been going after the low-hanging fruit
> in our use of PostgreSQL.  When we get to the main applications, we're
> going to be dealing with a lot more in the way of EXISTS clauses.  The
> product we're moving from usually optimized an IN test the same as the
> logically equivalent EXISTS test, and where a difference existed, it
> almost always did better with the EXISTS -- so we encouraged application
> programmers to use that form.  Also, EXISTS works in situations where
> you need to compare on multiple columns, so it is useful in many
> situations where EXISTS or MIN/MAX techniques just don't work.
> </digression>

Maybe it's just the way my twisted mind thinks, but I generally prefer
using a JOIN when possible...
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software    work: 512-231-6117
vcard:       cell: 512-569-9461

In response to


pgsql-performance by date

Next:From: Jim C. NasbyDate: 2006-02-28 21:09:25
Subject: Re: fsync and battery-backed caches
Previous:From: Kevin GrittnerDate: 2006-02-28 18:16:50
Subject: Re: [PERFORM] temporary indexes

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2006-02-28 21:15:31
Subject: Re: [PERFORM] temporary indexes
Previous:From: Tom LaneDate: 2006-02-28 19:49:31
Subject: Re: character encoding in StartupMessage

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