> I asked the question how do you get a record without going through an
> index, the answer was CTID, which unfortunately changes when the row is
> updated.
The ctid is a physical location of the row. On update a new tuple is written
in a new location, that is why the ctid changes. The old tuple
> Lately, I have been thinking that a cool form of index would be some
sort
> of "persistent reference" index. Like the old ISAM days of yore, a
fixed
> number could point you right to the row that you want. I'm not sure if
the
> "persistent reference" is a specific auto numbering column type or
>
s to the table, re-cluster it.
Yea, like I said, there are easier ways of doing that with fairly static
data.
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, February 10, 2005 11:22 AM
>> To: pgsql-hackers@postgr
Title: RE: [HACKERS] New form of index "persistent reference"
If that ID is the only thing you use to access that data, why not just store it in a flat file with fixed-length records? seek() (or your language's equivalent) is usually fast.
If you need to drive that from wi
For about 5 years now, I have been using a text search engine that I wrote
and maintain.
In the beginning, I hacked up function mechanisms to return multiple value
sets and columns. Then PostgreSQL aded "setof" and it is was cool. Then it
was able to return a set of rows, which was even better.
L