Re: [HACKERS] New form of index "persistent reference"

2005-02-11 Thread Zeugswetter Andreas DAZ SD
> 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

Re: [HACKERS] New form of index "persistent reference"

2005-02-10 Thread Merlin Moncure
> 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 >

Re: [HACKERS] New form of index "persistent reference"

2005-02-10 Thread pgsql
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

Re: [HACKERS] New form of index "persistent reference"

2005-02-10 Thread Bort, Paul
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

[HACKERS] New form of index "persistent reference"

2005-02-10 Thread pgsql
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