CBlog

Schöner Titel zum Mitraten, oder? ;-)

Paste Search ist ein unspektakuläres PHP-Script, das aber die Usability von Konqueror (und anderen Webbrowsen) enorm verbessert. Konkret geht es um das Verhalten beim "Mittelklicken" des Browserfensters, das normalerweise eine Google-Suche auslöst und nach dem Begriff in der Zwischenablage sucht. Dieses Standardverhalten ist schonmal gut, aber oft habe ich andere Ziele - beispielsweise ein Bugreport auf bugzilla.novell.com oder im SourceForge Tracker.

Die Lösung ist relativ einfach: Das folgende PHP-Script wird auf einen Webserver hochgeladen und als Standard-Suchmaschine im Browser eingetragen. Ab diesem Zeitpunkt wird bei Zahlen automatisch im Bugtracker gesucht (die Unterscheidung erfolgt anhand der Nummer - alles bis 500000 geht an bugzilla.novell.com, der Rest an SourceForge), bei Text mit Google.

Nice title to guess on, right? ;-)

Paste Search is an unspectacular PHP script that greatly enhances the usability of Konqueror (and other web browsers). To be exact, it is about the behaviour when "middle-clicking" the browser window which usually starts a google search for the content of the clipboard. This default behaviour is not bad, but sometimes I have other targets - for example bugreports on bugzilla.novell.com or in the SourceForge trackers.

The solution is quite simple: Upload the following PHP script to a webserver and configure your browser to use it as default search engine. If you paste numbers to your browser now, it will go to the bugtracker automatically (the selection depends on the bug number - up to 500000 goes to bugzilla.novell.com, everything above to the SourceForge tracker). If you paste text, you will be redirected to Google.

<?php # cbPasteSearch.php
if (empty($_GET['q'])) {
    echo "Please run me with ?q=searchterm";
} else {
    $q = trim($_GET['q']);
    if (preg_match("/^[0-9]+$/", $q)) { # numeric
        if ($q < 500000) { # Novell bugzilla
            header("Location: https://bugzilla.novell.com/show_bug.cgi?id=$q");
        } else { # SF tracker
            header("Location: https://sourceforge.net/support/tracker.php?aid=$q");
        }
    } else { # not numeric - ask Google
            header("Location: http://www.google.de/search?q=$q");
    }
}
?>

Natürlich kann man sich das Script nach Bedarf durch zusätzliche if-Abfragen anpassen. Vorschläge dazu nehme ich in den Kommentaren gern entgegen ;-)

Of course you can customize the script as needed by adding additional if statements. Please add your ideas to the comment section ;-)

Hätte ich diesen Artikel zwei Stunden früher gepostet, hätte man ihn für einen Aprilscherz gehalten: Ich habe gestern eine MySQL-Query bei gleichem Ergebnis um den Faktor 1000 beschleunigt. Das Ganze ohne irgendwelche Änderungen an der Datenbank oder der MySQL-Konfiguration, sondern nur durch Änderung der Query.

Das ist die ursprüngliche Query (etwas vereinfacht, im Original wurden noch ein paar mehr Felder SELECTed):

SELECT 
a.id,a.rubrik,a.sort,
b.id as rid,b.verfall as rverfall,
c.id as sid,c.verfall as sverfall,
d.id as kid,d.verfall as kverfall
FROM a,b,c,d
WHERE a.rubrik=24 AND
(a.id = b.id OR a.id = c.id OR a.id = d.id) AND 
(b.verfall >=now() OR c.verfall >=now() OR d.verfall >=now())
GROUP BY a.id
ORDER BY a.sort;

Laufzeit dieser Abfrage sind gut 3 Sekunden bei einem recht kleinen Datenbestand (b, c und d haben jeweils rund 100 Datensätze, a hat "immerhin" 380). Das Ergebnis der Query sind lächerliche 8 Datensätze.

Bei einem so kleinen Datenbestand ist die hohe Laufzeit doch recht verwunderlich. Ich wage zu behaupten, dass man die Daten per RTP (Rauchzeichen Transfer Prototokoll ;-) schneller aus der Datenbank bekommen hätte...

Sieht man sich die Abfrage mit EXPLAIN an, sieht man einen Teil der Ursache: Es wird eine temporäre Tabelle angelegt. (Waaas?! Für 8 Datensätze?!). Verständlich wird das Problem, wenn man einmal das "GROUP BY" weglässt. Das Ergebnis enthält dann rund 15.000 Datensätze - davon 14.992 Duplikate, die durch die impliziten JOINs ("WHERE ... a.oid=b.oid") erzeugt werden. Dass man für diese Datenmenge eine temporäre Tabelle braucht, ist schon weniger verwunderlich ;-) aber trotzdem nicht akzeptabel.

Die überarbeitete Query sieht dann so aus:

SELECT a.rubrik,a.id,a.tabname,a.sort,
b.id as rid,b.verfall as rverfall
FROM a,b
WHERE a.rubrik=24 AND a.id = b.id AND b.verfall >=now()
UNION
SELECT a.rubrik,a.id,a.tabname,a.sort,
c.id as sid,c.verfall as sverfall
FROM a,c
WHERE a.rubrik=24 AND a.id = c.id AND c.verfall >=now()
UNION
SELECT a.rubrik,a.id,a.tabname,a.sort,
d.id as kid,d.verfall as kverfall
FROM a,d
WHERE a.rubrik=24 AND a.id = d.id AND d.verfall >=now() 
ORDER BY a.sort;

Wie man sieht, braucht diese Abfrage kein GROUP BY, weil sie keine überflüssigen Duplikate produziert. Das wirkt sich auch sehr positiv auf die Laufzeit aus - nur noch 0,003 Sekunden und somit ein Tausendstel der alten Query :-)

Danke, Kris für die MySQL-Dienstage in Deiner Zeit in Karlsruhe, bei denen man u. a. solche Dinge lernen konnte. Ja, ich lese Dein Blog immer noch ;-) - unter anderem wegen der hervorragenden technischen Artikel.