Re: write sets and read sets

Hi Alex,

Alex Pilchin wrote:
...
> Well, I'm working on a research project and I understand it should be
> significantly faster to apply write sets rather than rerun the SQL
> query. I would like to store the write sets and then apply them directly
> on the same database (where "same" means any state equivalent DB) at a
> later time.

May it be possible that there is some misunderstanding?

When we talk about read_set/write_set, we mean a set of bits, a bitmap.

Every bit represents a column of the table that the set belongs to. For every statement, read_set gets the bits set for the columns that need to be read from that table by the statement, write_set gets the bits set for the columns that are written to that table by the statement. If a statement handles more than one table, then there is one pair of read_set/write_set per table. All of them can be set differently.

These bitmaps are computed during parsing and executing the statement. They are used by the table handler to optimize access of its records. Due to read_set it needs to retrieve certain parts of a record only. Due to write_set, it needs to modify certain parts of a record only.

I fail to see what one could accomplish by copying these bitmaps elsewhere. When you use other table handlers or other tables, you need a different statement, if only to exchange the table names. The execution machine needs to initialize itself from that statement anyway. So the bitmaps are a natural by-product. Copying them could only make the statement fail. Different handlers may require different bits to be set (primary key requirements, etc).

If you still talk about these bitmaps, then please provide more information about your project. Otherwise I don't know how to help.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

Regards
Ingo

-- 
Ingo Strüwing, Senior Software Developer
MySQL GmbH, Radlkoferstr. 2, D-81373 München
Geschäftsführer: Kaj Arnö - HRB München 162140

-- 
MySQL Internals Mailing List
For list archives: 
http://lists.mysql.com/internals
To unsubscribe:    
http://lists.mysql.com/internals?unsub=lists@pantek.com