Re: Is there going to be a port to Solaris 9 x86 in the

From: Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is there going to be a port to Solaris 9 x86 in the
Date: 2003-11-19 11:17:56
Message-ID: bxyptfoobdn.fsf@datafix.cs.berkeley.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

>>>>> "Greg" == Greg Stark <gsstark(at)mit(dot)edu> writes:

Greg> I think you're talking about situations like "where x = ? or
Greg> y = ?" or "where x = ? and y = ?"

Greg> When both `x' and `y' are indexed. It's possible to do the
Greg> index lookup, gather a list of tid pointers in some
Greg> efficient format like a bit vector, and apply the and/or and
Greg> any other clauses.

Yes, Index ANDing/ORing are useful whether or not the list of tids are
in an efficient format. Especially ORing for performing disjunctions.

Greg> Oracle can do this, and it's useful in some cases when you
Greg> have DSS-style where all the indexes have poor selectivity
Greg> but using enough of them together gets you a reasonable
Greg> number of records.

I guess this is the piece where "variant indexes" is useful -
essentially when you have a large number of matches for a given key.

I'm not sure how useful it is in practice - I've only read the
original research paper.

Greg> I think this is different from what he meant, but yes,
Greg> bitmap indexes might be an interesting project. Like hash

You're right .. a sorted TLF is really something quite simple that can
make quite a difference in accessing a non-clustered index. I believe
this is something all the commercial guys do. Sorting the Tids before
fetching 'em buys you buffer cache locality. When there are large
numbers of hits, it also buys you sequential scans where the file
system prefetcher can help. The additional overhead you pay is the
sorting cost.

--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Merlin Moncure 2003-11-19 13:03:53 Re: 7.4 not yet covered on /.
Previous Message Shridhar Daithankar 2003-11-19 06:37:54 Re: Slashdot

Browse pgsql-hackers by date

  From Date Subject
Next Message strk 2003-11-19 12:35:55 initdb segfaults - latest cvs
Previous Message Lee Kindness 2003-11-19 11:02:59 ECPG: "EXEC SQL CREATE SCHEMA foo" Broken