This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
admin:optimization:plans:home [2012/02/02 01:40] doc |
admin:optimization:plans:home [2016/06/28 22:38] (current) |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| {{page>:top_add&nofooter&noeditbtn}} | {{page>:top_add&nofooter&noeditbtn}} | ||
| - | ====== Administration ====== | + | ====== Administration: Optimizing Queries ====== |
| - | ===== Optimizing Queries ===== | + | ===== Query Plans ===== |
| **[[admin:optimization:plans:home|Overview]]** | | **[[admin:optimization:plans:home|Overview]]** | | ||
| - | [[admin:optimization:plans:sections|Sections]] | | + | [[admin:optimization:plans:reference|Anatomy of a Query Plan]] | |
| - | [[admin:optimization:plans:steps|Steps]] | | + | [[admin:optimization:plans:example|Reading a Query Plan]] | |
| - | [[admin:optimization:plans:optimized|Fully Optimized Queries]] | + | [[admin:optimization:plans:configuration|Configuring Query Plans]] | |
| + | [[admin:optimization:plans:optimization|Optimizing Queries]] | ||
| ---- | ---- | ||
| - | \\ | + | |
| ==== Overview ==== | ==== Overview ==== | ||
| - | Omnidex always optimizes a query as well as it can using the Omnidex indexes; however, if the indexes are not enough, Omnidex will complete the query without indexes, insuring the correct result. In fact, Omnidex can process queries even when no Omnidex indexes are available at all. In this way, Omnidex is first and foremost a SQL Engine for both relational and non-relational, or NoSQL, databases. | + | Omnidex always optimizes a query as well as it can using the Omnidex indexes; however, if the indexes are not enough, Omnidex will complete the query without indexes, insuring the correct result. In fact, Omnidex can process queries even when no Omnidex indexes are available. In this way, Omnidex is first and foremost a SQL Engine for both relational and non-relational, or NoSQL, databases. |
| - | Omnidex will evaluate the query and identify where indexes can be used. Omnidex evaluates the tables and their join relationships. Omnidex evaluates criteria, including nested queries, SQL functions and complex Boolean operations. Omnidex evaluates group by and order by, both to perform aggregations and to avoid unnecessary sorting of data. Omnidex even considers whether indexes can be used to return columns in the result set, avoiding accessing the data whenever possible. If there are not indexes to satisfy any of these steps, it will process then without the aid of indexing. | + | Omnidex will evaluate the query and identify where indexes can be used. Omnidex evaluates the tables and their join relationships. Omnidex evaluates criteria, including nested queries, SQL functions and complex Boolean operations. Omnidex evaluates GROUP BY and ORDER BY clauses, both to perform aggregations and to avoid unnecessary sorting of data. Omnidex even considers whether indexes can be used to return columns in the result set, avoiding access to the database whenever possible. In any of these situations, if there are not indexes to satisfy a step, it will process that part of the query without the aid of indexing. |
| The optimization plan for a query shows a sequence of steps, including table joins, processing criteria, aggregating data, and retrieving from the database. The ideal with Omnidex optimization is to avoid retrieving from the database if possible, and to fully optimize the query solely through the Omnidex indexes. If non-indexed steps are required, optimization tries to minimize these steps as much as possible. | The optimization plan for a query shows a sequence of steps, including table joins, processing criteria, aggregating data, and retrieving from the database. The ideal with Omnidex optimization is to avoid retrieving from the database if possible, and to fully optimize the query solely through the Omnidex indexes. If non-indexed steps are required, optimization tries to minimize these steps as much as possible. | ||
| - | ==== Optimizing a Sample Query ==== | + | ==== Obtaining a Query Plan ==== |
| - | + | ||
| - | The following is a rather straightforward query that joins two tables together --- Individuals and their respective Households --- and aggregates counts of all people born since 1980 that are either in Denver, CO or in Phoenix, AZ. The result is a display of counts by Gender. Let's take a look at how Omnidex optimizes this query. | + | |
| - | + | ||
| - | <html> | + | |
| - | <table width="90%"> | + | |
| - | <tr> | + | |
| - | <td valign="top"> | + | |
| - | <font face="'Courier New'"> | + | |
| - |   Select   I.GENDER, count(*) <br /> | + | |
| - |   from   HOUSEHOLDS H <br /> | + | |
| - |   join   INDIVIDUALS I <br /> | + | |
| - |   on   H.HOUSEHOLD = I.HOUSEHOLD <br /> | + | |
| - |    where   ((H.STATE = 'CO' and <br /> | + | |
| - |    H.CITY = 'Denver') or <br /> | + | |
| - |   (H.STATE = 'AZ' and <br /> | + | |
| - |    H.CITY = 'Phoenix')) and <br /> | + | |
| - |    I.BIRTHDATE > 'January 1, 1980' <br /> | + | |
| - |   group by   I.GENDER  | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | </table> | + | |
| - | </html> | + | |
| - | + | ||
| - | === Step 1: Determine the processing order === | + | |
| - | + | ||
| - | Omnidex must first determine the best processing order for the query. This is determined based on analyzing the table relationships and the select items. Generally speaking, Omnidex needs to end up in the table where the select items or aggregations reside, and must process the other tables first. In this example, Omnidex will recognize that the HOUSEHOLDS table is the parent table, and the query will aggregate data in the INDIVIDUALS table. It will process the HOUSEHOLDS criteria first. | + | |
| - | + | ||
| - | <html> | + | |
| - | <table width="90%"> | + | |
| - | <tr> | + | |
| - | <td colspan="3"> | + | |
| - | <font face="'Courier New'"> | + | |
| - | ----------------------------------- SUMMARY -----------------------------------</br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | <tr> | + | |
| - | <td valign="top" width="60%"> | + | |
| - | <font face="'Courier New'"> | + | |
| - |   Select   <font color=red>I.GENDER, count(*) </font><br /> | + | |
| - |   <font color=red> from   HOUSEHOLDS H <br /> | + | |
| - |   join   INDIVIDUALS I <br /> | + | |
| - |   on   H.HOUSEHOLD = I.HOUSEHOLD </font><br /> | + | |
| - |    where   ((H.STATE = 'CO' and <br /> | + | |
| - |    H.CITY = 'Denver') or <br /> | + | |
| - |   (H.STATE = 'AZ' and <br /> | + | |
| - |    H.CITY = 'Phoenix')) and <br /> | + | |
| - |    I.BIRTHDATE > 'January 1, 1980' <br /> | + | |
| - |   <font color=red>group by   I.GENDER </font><br /> | + | |
| - | </br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <-- <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | Since this query will aggregate the INDIVIDUALS <br /> | + | |
| - | table, Omnidex will process the HOUSEHOLDS table <br /> | + | |
| - | first and then end in the INDIVIDUALS table. <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | <tr> | + | |
| - | <td colspan="3"> | + | |
| - | <font face="'Courier New'"> | + | |
| - |   Version: 5.2.01 (Compiled Jan 23 2012 17:27:25) </br> | + | |
| - |   ----------------------------------- DETAILS -----------------------------------</br> | + | |
| - |   Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'Denver'; </br> | + | |
| - |   Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'CO'; </br> | + | |
| - |   Create index segment O1 on 1; </br> | + | |
| - |   Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'Phoenix'; </br> | + | |
| - |   Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'AZ'; </br> | + | |
| - |   Qualify (HOUSEHOLDS)HOUSEHOLDS where or $ODXID = 'segment(O1)'; </br> | + | |
| - |   Join HOUSEHOLDS using HOUSEHOLD to (INDIVIDUALS)INDIVIDUALS using HOUSEHOLD; </br> | + | |
| - |   Qualify (INDIVIDUALS)INDIVIDUALS where and BIRTHDATE > '"January 1, 1980"'; </br> | + | |
| - |   Aggregate INDIVIDUALS using GENDER for GROUP(GENDER), COUNT(*); </br> | + | |
| - |   Return I.GENDER, COUNT('*'); </br> | + | |
| - |   -------------------------------------------------------------------------------</br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | </table> | + | |
| - | </html> | + | |
| - | + | ||
| - | + | ||
| - | === Step 2: Process the HOUSEHOLDS table's criteria === | + | |
| - | + | ||
| - | Omnidex will perform index qualifications to process the criteria in the HOUSEHOLDS table, paying attention to Boolean operators and parentheses to insure the correct result. Once this is done, Omnidex will have isolated the rows that meet this criteria, identified by a temporary file containing index pointers. | + | |
| - | + | ||
| - | <html> | + | |
| - | <table width="90%"> | + | |
| - | <tr> | + | |
| - | <td colspan="3"> | + | |
| - | <font face="'Courier New'"> | + | |
| - | ----------------------------------- SUMMARY -----------------------------------</br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | <tr> | + | |
| - | <td valign="top" width="60%"> | + | |
| - | <font face="'Courier New'"> | + | |
| - |   Select   I.GENDER, count(*) <br /> | + | |
| - |   from   HOUSEHOLDS H <br /> | + | |
| - |   join   INDIVIDUALS I <br /> | + | |
| - |   on   H.HOUSEHOLD = I.HOUSEHOLD <br /> | + | |
| - |    where   <font color=red>((H.STATE = 'CO' and <br /> | + | |
| - |    H.CITY = 'Denver') or <br /> | + | |
| - |   (H.STATE = 'AZ' and <br /> | + | |
| - |    H.CITY = 'Phoenix'))</font> and <br /> | + | |
| - |    I.BIRTHDATE > 'January 1, 1980' <br /> | + | |
| - |   group by   I.GENDER <br /> | + | |
| - | </br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <-- <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | Omnidex will use the STATE and CITY indexes to process <br /> | + | |
| - | the HOUSEHOLDS table's criteria, paying attention to <br /> | + | |
| - | Boolean operators and parentheses. <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | <tr> | + | |
| - | <td colspan="3"> | + | |
| - | <font face="'Courier New'"> | + | |
| - | Version: 5.2.01 (Compiled Jan 23 2012 17:27:25) </br> | + | |
| - | ----------------------------------- DETAILS -----------------------------------</br> | + | |
| - | <font color=red> Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'Denver'; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'CO'; </br> | + | |
| - | Create index segment O1 on 1; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'Phoenix'; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'AZ'; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where or $ODXID = 'segment(O1)'; </font> </br> | + | |
| - | Join HOUSEHOLDS using HOUSEHOLD to (INDIVIDUALS)INDIVIDUALS using HOUSEHOLD; </br> | + | |
| - | Qualify (INDIVIDUALS)INDIVIDUALS where and BIRTHDATE > '"January 1, 1980"'; </br> | + | |
| - | Aggregate INDIVIDUALS using GENDER for GROUP(GENDER), COUNT(*); </br> | + | |
| - | Return I.GENDER, COUNT('*'); </br> | + | |
| - | -------------------------------------------------------------------------------</br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | </table> | + | |
| - | </html> | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | === Step 3: Join from HOUSEHOLDS to INDIVIDUALS === | + | |
| - | + | ||
| - | Omnidex will join from the HOUSEHOLDS table to the INDIVIDUALS table. Omnidex has several techniques for optimizing table joins. In this case, it will use the primary key values in HOUSEHOLDS as criteria against thed HOUSEHOLD index in the INDIVIDUALS table. Once this is done, Omnidex will have isolated rows in the INDIVIDUALS table that meet the criteria from the HOUSEHOLDS table. | + | |
| - | + | ||
| - | <html> | + | |
| - | <table width="90%"> | + | |
| - | <tr> | + | |
| - | <td colspan="3"> | + | |
| - | <font face="'Courier New'"> | + | |
| - | ----------------------------------- SUMMARY -----------------------------------</br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | <tr> | + | |
| - | <td valign="top" width="60%"> | + | |
| - | <font face="'Courier New'"> | + | |
| - |   Select   I.GENDER, count(*) <br /> | + | |
| - |   <font color=red>from   HOUSEHOLDS H <br /> | + | |
| - |   join   INDIVIDUALS I <br /> | + | |
| - |   on   H.HOUSEHOLD = I.HOUSEHOLD </font> <br /> | + | |
| - |    where   ((H.STATE = 'CO' and <br /> | + | |
| - |    H.CITY = 'Denver') or <br /> | + | |
| - |   (H.STATE = 'AZ' and <br /> | + | |
| - |    H.CITY = 'Phoenix')) and <br /> | + | |
| - |    I.BIRTHDATE > 'January 1, 1980' <br /> | + | |
| - |   group by   I.GENDER  | + | |
| - | </br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <br /> | + | |
| - | <-- <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <br /> | + | |
| - | Omnidex will apply primaryy keys from HOUSEHOLDS <br /> | + | |
| - | as criteria against the HOUSEHOLD index in <br /> | + | |
| - | INDIVIDUALS to process this join. <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | <tr> | + | |
| - | <td colspan="3"> | + | |
| - | <font face="'Courier New'"> | + | |
| - | Version: 5.2.01 (Compiled Jan 23 2012 17:27:25) </br> | + | |
| - | ----------------------------------- DETAILS -----------------------------------</br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'Denver'; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'CO'; </br> | + | |
| - | Create index segment O1 on 1; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where CITY = 'Phoenix'; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where and STATE = 'AZ'; </br> | + | |
| - | Qualify (HOUSEHOLDS)HOUSEHOLDS where or $ODXID = 'segment(O1)'; </br> | + | |
| - | <font color=red> Join HOUSEHOLDS using HOUSEHOLD to (INDIVIDUALS)INDIVIDUALS using HOUSEHOLD; </font> </br> | + | |
| - | Qualify (INDIVIDUALS)INDIVIDUALS where and BIRTHDATE > '"January 1, 1980"'; </br> | + | |
| - | Aggregate INDIVIDUALS using GENDER for GROUP(GENDER), COUNT(*); </br> | + | |
| - | Return I.GENDER, COUNT('*'); </br> | + | |
| - | -------------------------------------------------------------------------------</br> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | </table> | + | |
| - | </html> | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | === Step 4: Process the INDIVIDUALS table's criteria === | + | |
| - | + | ||
| - | Omnidex will perform index qualifications to process the criteria in the INDIVIDUALS table. This will further refine the index pointers already identified by processing in the HOUSEHOLDS table. | + | |
| - | + | ||
| - | <html> | + | |
| - | <table> | + | |
| - | <tr> | + | |
| - | <td valign="top"> | + | |
| - | <font face="'Courier New'"> | + | |
| - |   Select   I.GENDER, count(*) <br /> | + | |
| - |   from   HOUSEHOLDS H <br /> | + | |
| - |   join   INDIVIDUALS I <br /> | + | |
| - |   on   H.HOUSEHOLD = I.HOUSEHOLD <br /> | + | |
| - |    where   ((H.STATE = 'CO' and <br /> | + | |
| - |    H.CITY = 'Denver') or <br /> | + | |
| - |   (H.STATE = 'AZ' and <br /> | + | |
| - |    H.CITY = 'Phoenix')) and <br /> | + | |
| - |    <font color=red>I.BIRTHDATE > 'January 1, 1980'</font> <br /> | + | |
| - |   group by   I.GENDER  | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <-- <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | Omnidex will use the BIRTHDATE index to process the <br /> | + | |
| - | INDIVIDUALS table's criteria. | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | </table> | + | |
| - | </html> | + | |
| - | === Step 5: Aggregate counts in the INDIVIDUALS table=== | + | Query plans are produced using the EXPLAIN command in OdxSQL. A plan can be obtain by preceding the SELECT statement with the word EXPLAIN, as shown in the example below: |
| - | Omnidex will aggregate counts in the INDIVIDUALS table by scanning its indexes and filering the results using the index pointers set aside from the previous steps. | + | <code> |
| + | > explain select name, phone, email from individuals; | ||
| + | ----------------------------------- SUMMARY ----------------------------------- | ||
| + | Select NAME, | ||
| + | PHONE, | ||
| + | |||
| + | from INDIVIDUALS; | ||
| - | <html> | + | Version: 5.2.01 (Compiled Jan 23 2012 17:27:25) |
| - | <table> | + | Warnings: SEQUENTIAL_SCAN |
| - | <tr> | + | ----------------------------------- DETAILS ----------------------------------- |
| - | <td valign="top"> | + | Retrieve INDIVIDUALS sequentially; |
| - | <font face="'Courier New'"> | + | Return INDIVIDUALS.NAME, INDIVIDUALS.PHONE, INDIVIDUALS.EMAIL; |
| - |   Select   <font color=red>I.GENDER, count(*) </font><br /> | + | ------------------------------------------------------------------------------- |
| - |   from   HOUSEHOLDS H <br /> | + | </code> |
| - |   join   INDIVIDUALS I <br /> | + | |
| - |   on   H.HOUSEHOLD = I.HOUSEHOLD <br /> | + | |
| - |    where   ((H.STATE = 'CO' and <br /> | + | |
| - |    H.CITY = 'Denver') or <br /> | + | |
| - |   (H.STATE = 'AZ' and <br /> | + | |
| - |    H.CITY = 'Phoenix')) and <br /> | + | |
| - |    I.BIRTHDATE > 'January 1, 1980' <br /> | + | |
| - |   <font color=red>group by   I.GENDER </font> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | <-- <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | + | ||
| - | </font> | + | |
| - | </td> | + | |
| - | <td valign="top"> | + | |
| - | <font color=red> | + | |
| - | Omnidex will use the GENDER index to aggregate counts <br /> | + | |
| - | for the rows that have been isolated previously. <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | <br /> | + | |
| - | </font> | + | |
| - | </td> | + | |
| - | </tr> | + | |
| - | </table> | + | |
| - | </html> | + | |
| + | The EXPLAIN command can also follow a query in OdxSQL. It will provide a query plan for the query that was just executed. This approach has the advantage of having more statistics about the query; however, generating the query plan before the query is run has the advantage of checking a query before it consumes too many resources. | ||
| + | A plan consists of two sections: the Summary and the Details. The Summary section shows the SQL statement, the version of Omnidex, and any optimization warnings or suggestions about the query. The Details section shows the steps that will be executed to satisfy the query. | ||
| - | [[admin:optimization:plans:home| More >]] | + | In the simple example above, three columns are retrieved from the INDIVIDUALS table. Since no criteria was provided in a WHERE clause, the details of the plan show that the table is retrieved sequentially and the columns are returned. A simple warning indicates that a sequential scan is taking place, which in this case cannot be avoided. |
| + | |||
| ===== ===== | ===== ===== | ||
| ---- | ---- | ||
| \\ | \\ | ||
| - | **[[admin:optimization:overview:hdc|Next]]** | + | **[[admin:optimization:plans:reference|Next]]** |
| ====== Additional Resources ====== | ====== Additional Resources ====== | ||
| See also: | See also: | ||
| - | {{page>:admin:indexing:see_also&nofooter&noeditbtn}} | + | {{page>:admin:optimization:see_also&nofooter&noeditbtn}} |
| {{page>:bottom_add&nofooter&noeditbtn}} | {{page>:bottom_add&nofooter&noeditbtn}} | ||