• Previous message: [greg-dev] query analysis, part 1
  • Next message: [greg-dev] Re: query analysis, part 1
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    [greg-dev] query analysis, part 1

    Mike,
    
    thank you very much for your feedback.
    
    >
    > 1) These two are executed a lot, looks like on every page load.  What
    > can you tell me about them?  Is it necessary to run these so
    > frequently?  I imagine it's to do with PHP not being able to cache
    > these, but I don't know for sure since I'm not a PHP guy.
    
    Well, PHP is a web-oriented language, and thus state-less, unless we
    implement specific persistence mechanisms that keep the data across
    page requests.
    
    
    >   select key_,value_,default_,type_,desc_,export_  from  config
    >   select fk_ref_object_id, proptype, property, value from  properties
    >
    
    Okay, these two load the the configuration and object-properties, respectively.
    
    Sure, they are executed on every page load, but:
    
    1) Both tables hold a very limited number of rows (around 30 each) and
    
    2) We don't join any other table nor do we limit the rows in any way:
    we just ask mysql to dump the whole table. I'd say it's a fairly
    simple task for MySQL, isn't it?
    
    
    
    > Thoughts:
    > MySQL's query cache can mitigate this.
    > Many columns in these two tables are text, is this absolutely necessary?
    >
    
    I'm afraid it is, yes, unless we make the very large (300+) varchar's,
    which I think MySQL just treats as TEXT columns internally?
    
    
    
    >
    > 2) What in the world is this?  It is executed about half as much as #1
    > and I have no idea why.  Plus, it does a full table scan.
    >   select id from  channels  where url='S'
    >
    
    
    Odd. I just searched the whole codebase and can't really see where
    this is being queried.
    
    I guess you copy/pasted this from the output of the database
    profiling? Could you please give us some context? A couple lines
    before or after the query would help.
    
    By the way, we have an index on the URL column, and it seems to get used:
    
    http://www.nomorepasting.com/paste.php?pasteID=64812
    
    
    
    >
    > 3) This computed value should be stored!  It performs a full table
    > scan on item.  In my setup, that's 10,000 rows.
    >   select unix_timestamp(max(added)) as max_added from  item
    >
    > Thoughts:
    > Store one master timestamp in another table and update it each time an
    > item is added.  Then, just select that one timestamp.
    >
    
    Completely agree on this one: it's rather dumb to do it this way. I
    think we could store the value in the properties table, instead.
    
    
    Thanks again for your feedback, looking forward for more!
    
     -m
    
    Posted by Marco Bonetti [reply] at Wed Jul 5 21:43:58 CEST 2006