Re: Get the offset of a tuple inside a table - Mailing list pgsql-hackers

From Pei He
Subject Re: Get the offset of a tuple inside a table
Date
Msg-id AANLkTimZf-mvT1ZPqYmosnbSwZRe_5EsC9tC0Lh4wGvJ@mail.gmail.com
Whole thread Raw
In response to Re: Get the offset of a tuple inside a table  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Get the offset of a tuple inside a table
List pgsql-hackers
Hi Tom,
The bitmapset works for me.

I want to implement the operator for the following query:

Select * from a left join b on a.id = b.id order by b.id;

In a left outer join, I want the tuples that have matches in the inner table appear first. So, the order by clause is need.

If there is a index on a.id, I can use the tuples in b to probe the index.

After return all the tuples retrieved through index, it needs to return the rest tuples in a, because it is a left outer join in the query.

What I need to do is remember what have been returned by the index, and avoid to return it twice.

The bitmapscan needs to remember what have to been retrieved later, so it used the tidbitmap. But, for me, I need the bitmapset.
 
Thanks, your reply helps me to find the bitmapset.

Regards
--
Pei


On Tue, Sep 21, 2010 at 9:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pei He <hepeimail@gmail.com> writes:
> What I want to do is, for a given key return the tuples that Index scan can
> find, and return the rest tuples by a seq scan. So, I need to know which
> tuples have been returned by maintain a bitmap, and to avoid return the same
> tuple twice.

> If I can know the offset of a tuple in the order of file scan, then I can
> force the seq scan to skip it.

As pointed out, "offset" is an unworkable concept here.  That's why the
tidbitmap code doesn't work with offsets; it works with tids.  You don't
really need to reinvent this wheel.  Go read the bitmapscan code.

(One wonders though what you think you are going to save if you have to
do a seqscan anyway.  Where's the advantage over just doing a seqscan?)

                       regards, tom lane

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Shutting down server from a backend process, e.g. walrceiver
Next
From: Bruce Momjian
Date:
Subject: Re: Multi-branch committing in git, revisited