Re: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Scan by TID (was RE: [HACKERS] How to add a new build-in operator)
Date: 1999-10-12 15:02:09
Message-ID: 16598.939740529@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> If we put something in the executor so when a sequential/index scan is
> requested on a table that has a restriction on tid, you could just do a
> heap_fetch and return the single row, rather than putting the query
> through the whole scan process for every row checking to see if it
> matches the WHERE restriction.

> Seems like a few lines in the executor could do the entire job of
> fetching by tid by short-circuiting the sequential/index scan.

If I understand what you're proposing here, it would be a horrible
mangling of the system structure and doubtless a fruitful source
of bugs. I don't think we should be taking shortcuts with this issue.
If we think fast access by TID is worth supporting at all, we should
expend the work to do it properly.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-10-12 15:08:43 Re: [HACKERS] Dead CVS directories
Previous Message Peter Mount 1999-10-12 14:57:45 RE: [HACKERS] Dead CVS directories