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
>