Re: No heap lookups on index

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: David Scott <davids(at)apptechsys(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: No heap lookups on index
Date: 2006-01-19 22:50:39
Message-ID: Pine.LNX.4.63.0601191433110.1906@garibaldi.apptechsys.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Thu, 19 Jan 2006, Jim C. Nasby wrote:

> Do you still have that patch that folks could look at? ISTM that this
> technique would be rather dependant on your actual workload, and as such
> could result in a big win for certain types of queries.

It is not a patch, per se. It is a c language function which calls some
of the nbtree functions to return things from the index. The syntax for
calling it is rather obtuse, since those of us who don't understand the
parser are doomed to attempt circumventing it ;P.

I tarred up the code, and put it on a web server so that interested
parties can play with it. The url is
http://linux.apptechsys.com/~jeremyd/postgresql/fakeidxscan.tar.gz

It is very hackish, so definately do not assume that it is in any way
correct, rather assume the opposite. I have run it on x86 and x86_64
boxes, and it compiles and runs on those.

Here is an example of its usage, so you can see the nasty syntax required
and perhaps grok how to use it better.

create table test_table (a integer, b integer);
create index test_table_a_b_idx on test_table (a, b);
insert into test_table (a, b) select a, b from generate_series(1,100) a,
generate_series(1,100) b;

select * from fakeidxrowscomposite(
'test_table', -- relation
'test_table_a_b_idx', -- index
1, --number of scan keys
ARRAY[1, 2]::smallint[], -- numbers of the index attributes to return
ARRAY[1]::smallint[], -- numbers of the attrs the scankeys apply to
ARRAY['=(integer,integer)'::regoperator], -- operators for the scankeys
ARRAY[3]::smallint[], -- btree strategy for the scankeys
(42,0) -- values for the scankeys to compare against (if there is only
-- one, you have to put a fake one in since otherwise the parser
-- does not think it is a record)
) AS (a integer, b integer); -- tell the parser what columns to expect

This example returns 100 rows in which the first column contains 42 and
the second column contains the numbers between 1 and 100, in order.

Feel free to do whatever with this, it's pretty fast for tables where
seeks to validate tuples would hurt, but you do get back dead things...

--
When you know absolutely nothing about the topic, make your forecast by
asking a carefully selected probability sample of 300 others who don't
know the answer either.
-- Edgar R. Fiedler

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2006-01-19 22:53:14 Re: A tale of two similar databases
Previous Message Doug McNaught 2006-01-19 22:47:33 Re: Upgrade Problem: 7.4.3 -> 8.1.2

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-01-19 22:50:59 Re: PostgreSQL and shared memory.
Previous Message Bruce Momjian 2006-01-19 22:49:35 Re: Bug: random() can return 1.0