Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 5C57A9FB25C for ; Thu, 1 Feb 2007 13:25:57 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 53526-02 for ; Thu, 1 Feb 2007 13:25:48 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.metronet.co.uk (mail.metronet.co.uk [213.162.97.75]) by postgresql.org (Postfix) with ESMTP id 1C1A79FB412 for ; Thu, 1 Feb 2007 13:23:53 -0400 (AST) Received: from server3.office.archonet.com (84-51-143-99.archon037.adsl.metronet.co.uk [84.51.143.99]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP id CAA2173E4E; Thu, 1 Feb 2007 17:23:47 +0000 (GMT) Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id AD91D274053; Thu, 1 Feb 2007 17:23:47 +0000 (GMT) Message-ID: <45C22223.1090909@archonet.com> Date: Thu, 01 Feb 2007 17:23:47 +0000 From: Richard Huxton User-Agent: IceDove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: Michael Artz Cc: pgsql-performance@postgresql.org Subject: Re: Subselect query enhancement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200702/3 X-Sequence-Number: 23057 Michael Artz wrote: > I'm needing help determining the best all-around query for the > following situation. Not sure whether such a beast exists, but... > I have primary table that holds ip information > and two other tables that hold event data for the specific IP in with > a one-to-many mapping between them, ie: [snip] > There is quite a bit of commonality between the network_events and > host_events schemas, but they do not currently share an ancestor. > ip_info has about 13 million rows, the network_events table has about > 30 million rows, and the host_events table has about 7 million rows. > There are indexes on all the rows. What indexes though. Do you have (name,ip) on the two event tables? How selective is "name" - are there many different values or just a few? If lots, it might be worth increasing the statistics gathered on that column (ALTER COLUMN ... SET STATISTICS). http://www.postgresql.org/docs/8.2/static/sql-altertable.html > The query that I would like to execute is to select all the rows of > ip_info that have either network or host events that meet some > criteria, i.e. name='blah'. I have 3 different possibilities that I > have thought of to execute this. > > First, 2 'ip IN (SELECT ...)' statements joined by an OR: > > SELECT * FROM ip_info > WHERE ip IN (SELECT ip FROM network_events WHERE name='blah') > OR ip IN (SELECT ip FROM host_events WHERE name='blah'); > > Next, 1 'ip IN (SELECT ... UNION SELECT ...) statement: > > SELECT * FROM ip_info > WHERE ip IN (SELECT ip FROM network_events WHERE name='blah' > UNION > SELECT ip FROM host_events WHERE name='blah'); > > Or, finally, the UNION statment with DISTINCTs: > > SELECT * FROM ip_info > WHERE ip IN (SELECT DISTINCT ip FROM network_events WHERE name='blah' > UNION > SELECT DISTINCT ip FROM host_events WHERE name='blah'); > > From what I have read, the UNION statement does an implicit DISTINCT, > but I thought that doing it on each of the tables would result in > slightly faster execution. Can you think of any other ways to > implement the previous query? You're right about removing duplicates. Not sure whether the DISTINCTs on the sub-selects are helping or hindering. It'll probably depend on your hardware, config, number of rows etc. The only other way I can think of for this query is to UNION two JOINs. Might interact well with the (name,ip) index I mentioned above. > I have explained/analyzed all the queries but, unfortunately, they are > on an isolated computer. The gist is that, for relatively > low-incidence values of name, the UNION performs better, but for > queries on a common name, the dual-subselect query performs better. Difficult to say much without seeing the full explain analyse. Did the row estimates look reasonable? -- Richard Huxton Archonet Ltd