[Phpmyadmin-devel] Zoom-search and initial data reading

Piotr Przybylski piotr.prz at gmail.com
Thu Aug 4 13:31:52 CEST 2011

2011/8/4 Marc Delisle <marc at infomarc.info>:
> Piotr Przybylski a écrit :
>> 2011/8/4 Ammar Yasir <ayax88 at gmail.com>:
>>> On Thu, Aug 4, 2011 at 2:01 AM, Marc Delisle <marc at infomarc.info> wrote:
>>>> Ammar Yasir a écrit :
>>>>> On Wed, Jul 27, 2011 at 10:22 PM, Ammar Yasir <ammaryasir.88 at gmail.com
>>>>> <mailto:ammaryasir.88 at gmail.com>> wrote:
>>>>>     On Wed, Jul 27, 2011 at 3:37 PM, Marc Delisle <marc at infomarc.info
>>>>>     <mailto:marc at infomarc.info>> wrote:
>>>>>         Ammar,
>>>>>         With Firebug I had a look at the network traffic when I click a
>>>>> data
>>>>>         point to edit it: I was surprised to see none.
>>>>>         IMO this is not good: it means that all the columns for all rows
>>>>>         are in
>>>>>         memory, making the browser able to handle far less rows.
>>>>>         Is there a reason why you are reading the complete rows to
>>>>>         generate the
>>>>>         plot? I expected that you would just read the necessary columns,
>>>>>         then
>>>>>         use AJAX to read a complete row when the user wants to edit it.
>>>>>     I'm currently working on the edit feature for strings. I'll work on
>>>>>     it after this.
>>>>>         --
>>>>> Implemented this and pushed to my repo. I only send the xField, yField
>>>>> and dataLabel to the user now.
>>>> Ammar,
>>>> you have reduced the amount of data transferred between the PHP level
>>>> and the Javascript level, by sending less data in the querydata div.
>>>> Can you also reduce what is transferred between the MySQL server and the
>>>> web server, by avoiding to generate "SELECT *" in the query generation
>>>> part, instead selecting only the needed columns?
>>> That would have been the ideal case but to generate the unique-condition(
>>> function PMA_getUniqueCondition($handle, $fields_cnt, $fields_meta, $row,
>>> $force_unique=false) ), I need the complete row. So I cannot do much about
>>> the query generation on the server side other than putting a limit on the
>>> number of rows retrieved.
>> It will increase complexity o bit but you can do one of the two:
>> - select one full row with "SELECT * FROM ... LIMIT 1" (any full row
>> will do so no ORDER here) and analyze which rows you need by looking
>> for primary/unique key fields,
>> - if you have only one table you can analyze SHOW CREATE TABLE
>> statement and look for PRIMARY KEY and UNIQUE constraints
> But PMA_getUniqueCondition() also handles the case when there is no
> unique key.

Yes, but in most cases there is one. If there is no unique key then
'SELECT *' is needed, but if there is one then the built query can
return smaller result, without useless columns.

Piotr Przybylski

More information about the Developers mailing list