Re: Including Snapshot Info with Indexes

Gokulakannan Somasundaram wrote:
> Hi Heikki, I am always slightly late in understanding things. Let me
> try to understand the use of DSM. It is a bitmap index on whether all
> the tuples in a particular block is visible to all the backends,
> whether a particular block contains tuples which are invisible to
> everyone. But i think this will get subjected to the same limitations
> of Bitmap index. Even Oracle suggests the use of Bitmap index for
> only data warehousing tables, where the Bitmap indexes will be
> dropped and recreated after every bulk load. This is not a viable
> alternative for OLTP  transactions. But i think i am late in the game
>  as i haven't participated in those discussions
While the DSM might be similar in spirit to a bitmap index, the actual
implementation has a lot more freedome I'd say, since you can tailor it
exactly to the need of tracking some summarized visibility info. So not
all shortcomings of bitmap indices must necessarily apply to the DSM
also. But of course thats mostly handwavering...

> One Bitmap index block usually maps to lot of blocks in the heap. So
> locking of one page to update the DSM for update/delete/insert would
> hit the concurrency. But again all these are my observation w.r.t
> oracle bitmap indexes. May be i am missing something in DSM.
A simple DSM would probably contain a bit per page that says "all xmin <
GlobalXmin, and all xmax unset or aborted". That bit would only get SET
during VACUUM, and only unset during INSERT/UPDATE/DELETE. If setting it
is protected by a VACUUM-grade lock on the page, we might get away with
no locking during the unset, making the locking overhead pretty small.


> I couldn't get that piece of discussion in the archive, which 
> discusses the design of Retail Vacuum. So please advise me again
> here. Let's take up Retail Vacuuming again. The User defined function
>  which would return different values at different time can be
> classified as non-deterministic  functions. We can say that this
> index cannot be created on a non-deterministic function. This is the
> way it is implemented in Oracle. What they have done is they have
> classified certain built-in operators and functions as deterministic.
> Similarly they have classified a few as non-deterministic operators
> and functions. Can we  follow a similar approach?
Postgres already distinguishes VOLATILE,STABLE and IMMUTABLE functions.
It doesn't, however, risk physical data corruption, even if you get that
classification wrong. The worst that happens AFAIK are wrong query
results - but fixing your function, followed by a REINDEX always
corrects the problme. If you start poking holes into that safety net,
there'll be a lot of pushback I believe - and IMHO rightly so, because
people do, and always will, get such classifications wrong.

greetings, Florian Pflug