Re: Further open item (Was: Status of 7.2)

Tille, Andreas wrote:

>On Tue, 20 Nov 2001, Bruce Momjian wrote:
>
>>So, while we do have plans to mark some index tuples so we _know_ they
>>are expired, we don't know how to efficiently mark index tuples so we
>>_know_ they are valid.
>>
>>This is what I believe you want, where we can scan the index without
>>checking the heap at all.
>>
>An new index type (say READONLY INDEX or some reasonable name) which is
>valid all the time between two vacuum processes would suffice for my
>application.  It would fit the needs of people who do a daily database
>update and vacuum after this.
>
Or perhaps MAINTAINED INDEX, meaning that it has always both tmin and tmax
up-to-date.
Btw 7.2 still has broken behaviour of xmax which by definition should 
not have a
non-0 value for live tuples

pg72b2=# create table parent(pid int primary key);
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 
'parent_pkey' for table 'parent'
CREATE
pg72b2=# create table child(cid int, pid int references parent);
NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY 
check(s)
CREATE
pg72b2=# insert into parent values(1);
INSERT 16809 1
pg72b2=# insert into child values(1,1);
INSERT 16810 1
pg72b2=# update child set pid=2;
ERROR:  <unnamed> referential integrity violation - key referenced from 
child not found in parent
pg72b2=# select xmin,xmax,* from child;
 xmin | xmax | cid | pid
------+------+-----+-----
  171 |  172 |   1 |   1
(1 row)

pg72b2=#

>
>
>Of course it´s your descision if this makes sense and fits PostgreSQL
>philosophy, but I think it would speed up some kind of applications.
>
>Kind regards
>
>         Andreas.
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>subscribe-nomail command to majordomo@postgresql.org so that your
>message can get through to the mailing list cleanly
>