-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, null AS theAlias1, null AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

In my case the result of the query will be inserted in a temporary table in memory. The destination column for theAlias1 is of type INTEGER. When executing the query PostgreSQL gives me an error:

column "theAlias1" is of type integer but expression is of type text

So there is something wrong when the query is parsed, evaluated and executed.

Solving this was easy with the use of NULLIF. Zero equals zero so NULL is returned. Just as expected.

-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, NULLIF(0, 0) AS theAlias1, NULLIF(0, 0) AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

Im Kern wird die schnellere Ausfuehrung der Query dadurch realisiert, dass mittels der WITH-Klausel die Ergebnismenge der Subquery vorab materialisiert, mit einem Namen versehen und schliesslich in der Hauptquery abgegriffen wird.
Hier lohnt sich auch ein Vergleich und Gebrauch von "global temporary tables", die in Ihrer Funktions- und Wirkungsweise durchaus ähnlich sind:
Durch Entkopplung geeigneter Subqueries, die urspruenglich als Bestandteile einer komplexen Abfrage fungierten, wird dieses SQL-Statement vereinfacht.

WITH   SQ1 AS (SELECT...FROM...WHERE...),
       SQ2 AS (SELECT...FROM...WHERE...)
SELECT...
  FROM Q1, SQ1, SQ2 WHERE…

Interessanter Nebeneffekt:

Durch die Verwendung der WITH-Klausel wird anscheinend in einer Systemumgebung mit voreingestelltem CURSOR_SHARING=FORCE offensichtlich fuer die Query-Ausfuehrung diese systemweit gueltige Einstellung auf CURSOR_SHARING=EXACT zurueckgenommen (vergleichbar dem Einsatz des Hint /*+ cursor_sharing_exact */).

Zeigen die QEPs vorher noch eine allgemeine Ersetzung von Konstanten durch Parameter, so weisen die QEPs nachher die direkte Verwendung der Konstanten auf.

Somit orientiert sich der Optimizer auch grundsaetzlich an anderen Zugriffsstrategien.

Was in einer Umgebung mit problematischem Parseverhalten per Bindvariablen-Peeking einen "flüssigen" Anwendungsbetrieb ermöglichen kann, wird im Einzelfall einer komplexen Query unter Verwendung von Attributen mit stark ungleicher Werteverteilung zu relativ kostenintensiven QEPs führen.

Es empfiehlt sich dann für alle entsprechenden Konstanten/Parameter einen separaten und speziellen QEP zu erzwingen.

Vorraussetzung:

SQL-99 Standard bzw. Oracle9i Release 2

Links:

SQLStandards.html

to be continued….

SELECT MIN(id)
     , MAX(id)
  FROM big_table

Bei diesem SELECT kommt zwar das richtige Ergebnis, dennoch kann die Antwortzeit sehr lange dauern. Der Grund liegt in einem FAST FULL INDEX SCAN.

Besser ist folgendes:

SELECT MIN(id) min_value
  FROM big_table
 UNION ALL
SELECT MAX(id) max_value
  FROM big_table

oder

SELECT (SELECT MIN(id) from big_table) min_value
      ,(SELECT MAX(id) from big_table) max_value
  FROM dual

Bei beiden alternativen wird ein FULL INDEX SCAN durchgeführt und liefert das Ergebnis (fast) sofort zurück.
Den Umweg sollte man bei großen Tabellen und wo es auf Geschwindigkeit ankommt wählen.

SELECT
     , b.username blocking_username
     , b.osuser blocking_osuser
     , b.machine blocking_machine
     , b.program blocking_program
     , w.sid waiting_sid
     , w.username waiting_username
     , w.osuser waiting_osuser
     , w.machine waiting_machine
     , w.seconds_in_wait
  FROM v$SESSION w
     , v$SESSION b
 WHERE w.blocking_session is not NULL
   AND b.sid = w.blocking_session
 ORDER BY w.sid

Das Statement kann jederzeit um weitere Spalten erweitert werden.

Folgendes Beispiel soll die einfache Lösung aufzeigen:

SELECT a.id
     , a.parent_id
     , a.label
     , a.sort
  FROM menu_tree a
 ORDER BY 2 nulls first,1

(Abbildung 1: Unsortierte Basistabelle)

SELECT LEVEL
     , rpad(' ',LEVEL) || label
  FROM menu_tree a
 START WITH a.parent_id IS NULL
       CONNECT BY PRIOR a.id= a.parent_id
 ORDER siblings BY sort

(Abbildung 2: Sortiertes Ergebnis)

Debian lenny stable packages are bundled with Postgres 8.3.x but thanks to Debian Backports the newer Postgres version is available for lenny.

Simply do it

Add the backports-sources (/etc/apt/sources.list) and update (apt-get update)

deb http://www.backports.org/debian lenny-backports main contrib non-free

Install postgres

apt-get -t lenny-backports install postgresql-8.4

SELECT col1 FROM foobar WHERE col1 LIKE '1234%';

Yes?! Really?!

In one of our production systems this kind of query (when debugged via EXPLAIN / EXPLAIN ANALYZE) return unexpected results. Every time our comparison operator turns from equality = into LIKE the index for the column is fully ignored and instead a full-table scan (sequential scan) is used by the planner. Things are really slow …

I locale you!

After asking Google its seems some more people having this issue, too.
Our database-cluster was initialized with the locale de_DE.utf8. A quick view into the excellent documentation for CREATE INDEX revealed there is an operator class which controls the operators of the index. After adding an index with an operator class for that column the index (“FoobarWildcardIdx”) is now used even when the query contains LIKE.

CREATE INDEX FoobarWildcardIdx ON foobar (col1 varchar_pattern_ops);

Error

Clicking through the installation wizard went fine but then the installation cancelled with “nice” red error icons. A look into the logfile showed the following.

Property(S): ACTION = INSTALL
MSI (s) (08:D0) [23:01:25:354]: Note: 1: 1708
MSI (s) (08:D0) [23:01:25:354]: Produkt: MSXML 6.0 Parser (KB933579) -- Die Installation ist fehlgeschlagen.
 
MSI (s) (08:D0) [23:01:25:354]: Das Produkt wurde durch Windows Installer installiert. Produktname: MSXML 6.0 Parser (KB933579). Produktversion: 6.10.1200.0. Produktsprache: 1031. Erfolg- bzw. Fehlerstatus der Installation: 1603.
 
MSI (s) (08:D0) [23:01:25:385]: Cleaning up uninstalled install packages, if any exist

I downloaded the MSXML 6.0 Parser from the Microsoft Download page and tried to install it. Error! A newer product is already installed. A short look into “Software Installation” revealed that I have MSXML Parser 6.0 SP2 installed. Okay looks good for me but not for SQL Server 2008.

Being up-to-date is not always good

The installation routine depends on the installation of the MSXML Parser 6.0… In the end I uninstalled MSXML Parser 6.0 SP2 and started the installation again. Tadaaaa! It works. SQL Server was installed successfully. Now I can “re-apply” SP2 for the MSXML Parser 6.0

Woohoo

I started the windows command-line and entered date. It showed 2009-01-28. As you can see the year is 2009!
Having to do such steps to get an installation of SQL Server 2008 made me think I am in the year 1998! Wtf?!

Update: A friend of mine had problems with SQL Server 2008 installation, too.