Data Virtualization Demoette… Packaged Query Single Select Option Hello, and welcome to the Demoette series for Cisco Information Server, or CIS. Demoettes are brief instructional videos that demonstrate specific features of CIS. In this Demoette, we discuss the Packaged Query Single Select option.

Agenda What is it and why does it matter? A basic demo Summary Here is our agenda. We begin by defining the Packaged Query Single Select option and outlining its importance for our customers. Next we walk through a very basic demo of the Single Select option. Finally, we summarize the contents of this demoette.

Agenda What is it and whey does it matter? A basic demo Summary Let’s begin by discussing what the Single Select option is, and why it is important for our customers.

What is it? Packaged Query Single Select Option Packaged Queries enable CIS to execute non-standard data access statements If results must be filtered, CIS Optimizer cannot push down additional work If the Packaged Query is a single SELECT, the option may be selected Single Select permits more push-down by CIS As we have seen in a previous demoette, Packaged Queries are a way for CIS to execute non-standard data access statements by pushing them down unchanged to the underlying physical data source. This enables great flexibility for using non-standard statements with CIS, but it also limits the ability of the CIS optimizer to tune queries, because CIS cannot change the statements in the packaged query. For example, if we want to add a WHERE clause filter to the results of a packaged query, CIS cannot modify the packaged query to include this filter. Instead, CIS must retrieve the complete results of the packaged query, and perform the filtering itself. This can lead to inefficient network usage and longer response times for data consumers. However, if the packaged query is a single-statement operation that returns a result set, the Packaged Query Single Select option may be selected. This option enables CIS to modify the packaged query and push more work down to the physical data source.

Why does it matter? Packaged Query Single Select Option Makes CIS optimizer more powerful More work pushed to data source More efficient use of network Less processing required on CIS Server The Single Select option is important to our customers for several reasons. It gives more power to the CIS optimizer, enabling it to push more work down to data sources. This can result in faster processing, more efficient network usage, and faster throughput for data consumers, since less processing is required on the CIS server.

Agenda What is it and why does it matter? A basic demo Summary Next, let’s walk through a very basic demo of the Single Select option.

Demo: Here is the business problem… Here is the business problem that we illustrate in this demo. We are using a packaged query to access data on a PostgreSQL database. The packaged query lets us use PostgreSQL’s non-standard LIMIT keyword. We then use the packaged query in a virtual View, which adds a WHERE clause filter. Unfortunately, CIS must bring back the entire result set of the packaged query, and then filter the results. This means we are using the network inefficiently, and we are also adding to the processing load on CIS. In addition, the PostreSQL data source may have indexes defined that would make our filtering even more efficient. We’ll use the Single Select option to enable CIS to push the filter down to the data source and improve overall efficiency.

Before you begin: Import Optional CAR File You can easily build the resources needed for this demo from scratch. However, users may import a CAR file that is available with the Additional Resources that accompany this demo. The CAR file uses the Examples data that is delivered with CIS, so no new data source has to be configured.

Demo We’ll begin by showing the processing flow when the Single Select option is NOT chosen. This packaged query uses the non-standard LIMIT keyword, which postgres uses to limit the number of rows returned by a query. <CLICK> Note that the Single Select option is NOT chosen.

Demo Now we create a View that uses the packaged query, and adds a WHERE clause filter. <CLICK> As the execution plan shows. CIS must add its own filter step, because it cannot modify the packaged query in order to add the filter. This increases the amount of work that must be done on the CIS server, and it also forces us to bring unwanted rows over the network connection between postgres and CIS. <CLICK> We also see that CIS views the packaged query itself as simply a black box. It is viewed as a stored procedure that cannot be modified.

Demo Now let’s try the same packaged query, but with Single Select turned on.

Demo We create a view with the same filter. <CLICK> The execution plan is now simpler. The filter step is gone, and the Procedure step has been replaced by a Fetch. <CLICK> The Fetch step is interesting. With the Single Select option chosen, the original contents of the packaged query now appears enclosed in parentheses as a sub-select… <CLICK> … enabling the WHERE clause filter to be appended to the query. The filter now pushes down to the data source, which should be more efficient.

Demo Now we can understand why the Single Select option can only be used with packaged queries that perform a single select statement. Let’s use the multi-part option to create a new packaged query that performs a DELETE statement before the select. We’ll choose the Single Select option, which is invalid in this case. <CLICK> Now when we create a view using this packaged query, the execution plan embeds the packaged query contents in a sub-select. However, the sub-select is clearly not a valid SQL statement, and it will fail upon execution. We have seen both valid and invalid examples of the Packaged Query single select option. Our demo is complete.

Agenda What is it and why does it matter? A basic demo Summary Let’s summarize what we have seen in this presentation.

Summary Packaged Query Single Select Option Packaged Queries enable CIS to execute non-standard data access statements If results must be filtered, CIS Optimizer cannot push down additional work If the Packaged Query is a single SELECT, the option may be selected Single Select permits more push-down by CIS Makes CIS optimizer more powerful More work pushed to data source More efficient use of network Less processing required on CIS Server Packaged Queries are a way for CIS to execute non-standard data access statements by pushing them down unchanged to the underlying physical data source. This enables great flexibility for using non-standard statements with CIS, but it also limits the ability of the CIS optimizer to tune queries, because CIS cannot change the statements in the packaged query. For example, if we want to add a WHERE clause filter to the results of a packaged query, CIS cannot modify the packaged query to include this filter. Instead, CIS must retrieve the complete results of the packaged query, and perform the filtering itself. This can lead to inefficient network usage and longer response times for data consumers. However, if the packaged query is a single-statement operation that returns a result set, the Packaged Query Single Select option may be selected. This option enables CIS to modify the packaged query and push more work down to the physical data source. The Single Select option is important to our customers for several reasons. It gives more power to the CIS optimizer, enabling it to push more work down to data sources. This can result in faster processing, more efficient network usage, and faster throughput for data consumers, since less processing is required on the CIS server. Thank you.

TOMORROW starts here.