List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:May 16 2008 9:04pm
Subject:re: Safe to modify table->read_set?
View as plain text  

>>>>> "Timothy" == Timothy P Clark <Timothy> writes:


Timothy> However, I still have a problem when updating a row. This is because, for
Timothy> an UPDATE, my storage engine requires that all of the columns have correct
Timothy> data, even if some of the columns were not changed. Today, MySQL just
Timothy> requests those columns that are needed to select the row and those that are
Timothy> being updated. Therefore, for UDPATE, I need to override read_set to
Timothy> include all columns. There was apparently a patch committed that would have
Timothy> enabled the storage engine to notify MySQL that it needs this behavior
Timothy>, but I don't see this anywhere in
Timothy> 5.1.24. Is it coming? Or was this dropped?

It should be comming;  Will look into this.

There is two interim solutions:

- Detect in external lock that the statement is an update and use this
  information in your engine to read all columns.  (Fastest solution)
- In external lock or rnd_init(), index_init(), modify the read set to
  include all columns in case of update statement.
  In this context this is safe (even if it's not 100 % optimal as I
  described in my last email)

Timothy> It would be handy if I could (as necessary) overwrite the
Timothy> read_set at the
Timothy> beginning of each operation (i.e. in rnd_init and index_init) or
Timothy> when
Timothy> column_bitmaps_signal() is called.

See above.

>> Why would you like to modify the read/write set ?
>> There is normally no advantage at all in extending the read set.
>> The read set is mostly a way for MySQL to inform the engine which
>> columns you need to read (except in some error conditions).
>> Chaning the masks are likely to make things slower, as MySQL will
>> then have to do more work in some cases:
>> - Comparing which columns actually changed value
>> - Storing columns that are needed later in temporary tables / row caches.
>> The engine is free to read any column outside of the read set when
>> reading a row. It can then use this

Timothy> This is essentially what I'm currently doing... ignoring the read_set when
Timothy> thd_sql_command==update. However, it would simplify my logic and improve
Timothy> performance slightly if I could just rely on table->read_set.

In that case you should be able to do it, at a small cost.

>> Note that the 'original' row that you get as part of handler::update()
>> will include all column values from the read row, even if they where
>> not part of the read bitmap set.
>> To conclude:
>> - It's not safe to modify the read set, but there shouldn't ever be a
>> need to do that.

Timothy> If it's never safe, the comment in front of
Timothy> should probably be updated.

With 'safe', I was referring that you can't count on MySQL doing things
differently if you modify the read/write set.

It should however be safe, even not optimal for doing things in
rnd_init() or even column_bitmaps_signal().

Sorry for the confusion;  I didn't first exactly grasp what you wanted
to do...


Safe to modify table->read_set?Timothy P Clark15 May
  • re: Safe to modify table->read_set?Michael Widenius16 May
    • re: Safe to modify table->read_set?Timothy P Clark16 May
      • re: Safe to modify table->read_set?Michael Widenius16 May
      • Re: re: Safe to modify table->read_set?Sergei Golubchik17 May