Gokulakannan Somasundaram wrote:
> 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.
Well, it's not quite the same as a bitmap index, though both use a
bitmap. You didn't quite get into details on what the limitations are
and why it wouldn't be suitable for OLTP, but I don't see any
significant problems.
> But i think i am late in the game
> as i haven't participated in those discussions
Better late than never :).
> 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.
Yeah, the DSM page could become a contention bottleneck. My current
thinking is that we'd have a flag in the heap page header, that would be
set together with the bit in the DSM. When the flag in the page header
is set, you don't need to lock and update the DSM because you know the
bit is already set. Vacuum would have to clear both the DSM bit and the
flag.
> 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?
We already do. A function must be marked as IMMUTABLE in order to use it
in an index expression. But we can't enforce that the user defined
function really behaves like an immutable function should. If someone
creates a user-defined function in C that calls the C random() function,
we can't stop it.
As I said earlier, using an index like that will of course lead to bogus
results. But it won't currently cause any server crashes or more serious
corruption.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com