List:Internals« Previous MessageNext Message »
From:barries Date:April 1 2001 3:30pm
Subject:Re: Hacking triggers into 2.23.34a?
View as plain text  
On Sun, Apr 01, 2001 at 12:10:18PM +0300, Michael Widenius wrote:
> 
> Yes this should work ok as long as you don't do that in a loop!
> The reason is that each new_field allocates space which will not be
> freed until the SQL statement is completed.

I was planning on deleting them after each row or after each query,
depending on how constant table->field's pointers are.  I want to
minimize the scanning of table->field and the creation of old_fields.
I'd prefer to cache pointers to fields and to cache the old_fields.

When do the Fields pointed to table->field get exchanged for new fields?
In other words, when is it safe, if ever, to cache pointers to those
fields in List<Field> containers so the triggers don't need to rescan
that list each row or each query?

The reason I ask about the constancy of table->field is that is seems to
be pointing at one set of Field objects when attach_triggers() is called
from open_table():

    DBUG_PRINT("info", ("inserting table %p into the cache", table));
    VOID(hash_insert(&open_cache,(byte*) table));
    table->post_update_triggers=0;
    attach_triggers(db,table);
  }

  table->in_use=thd;
  check_unused();

and a different set when the triggers fire in mysql_update().  I've
started walking through it in gdb, but does the table->field array
ever become stable for the lifetime of the table?

As a side question: how does mysqld pack variable length columns into
record[0] and record[1] such that move_field() works?

> I could put this in our
> Patches section on the web page to make it easily accessible.

That would be just fine.  I'm also thinking that it'd be nice to combine
it with the embedded perl work going on and see if we can get Perl
language triggers.

Thanks again,

Barrie
Thread
Hacking triggers into 2.23.34a?barries29 Mar
  • Re: Hacking triggers into 2.23.34a?elble29 Mar
    • Re: Hacking triggers into 2.23.34a?barries29 Mar
      • Re: Hacking triggers into 2.23.34a?elble29 Mar
    • Re: Hacking triggers into 2.23.34a?Jeremy D . Zawodny29 Mar
      • Re: Hacking triggers into 2.23.34a?elble29 Mar
        • Re: Hacking triggers into 2.23.34a?barries29 Mar
          • Re: Hacking triggers into 2.23.34a?Sasha Pachev30 Mar
          • Re: Hacking triggers into 2.23.34a?barries30 Mar
            • Re: Hacking triggers into 2.23.34a?Michael Widenius31 Mar
        • Re: Hacking triggers into 2.23.34a?Sasha Pachev30 Mar
  • Re: Hacking triggers into 2.23.34a?Antony T Curtis30 Mar
  • Hacking triggers into 2.23.34a?Michael Widenius31 Mar
    • Re: Hacking triggers into 2.23.34a?barries31 Mar
      • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
        • Re: Hacking triggers into 2.23.34a?barries1 Apr
          • Re: Hacking triggers into 2.23.34a?barries1 Apr
            • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
              • Re: Hacking triggers into 2.23.34a?barries2 Apr
                • Re: Hacking triggers into 2.23.34a?Michael Widenius2 Apr
          • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
  • SQL92?Antony T Curtis2 Apr