Here are some numbers for 3 different queries using a very selective
query (port = 2222). I'm thinking that, since the row estimates are
different from the actuals (2 vs 2000), that this particular port
didn't make it into the statistics ... is that true? Does this
matter? If this isn't enough data, I can type up some more.
One thing that I forgot to mention is that the network_events and
host_events tables are partitioned by first octet of the IP, so when I
say "various scans of ..." that means that there is a scan of each of
the partitions, the type determined by the planner and the statistics,
I assume.
** Dual subselects:
SELECT * FROM ip_info
WHERE ip IN (SELECT ip FROM network_events WHERE port = 2222)
OR ip IN (SELECT ip FROM host_events WHERE port = 2222);
Seq scan on ip_info (cost=2776..354575 rows=9312338 width=72) (actual
time=34..8238 rows=234 loops=1)
Filter: ... AND ((hashed_subplan) OR (hashed_subplan))
Subplan
-> Result (cost=0..849 rows=459 width=4) (actual time=0.176..2.310
rows=72 loops=1)
-> Append (cost=0.00..849 rows=459 width=4) (actual
time=0.173..2.095 rows=72 loops=1)
-> various scans on host_events
-> Result (cost=0..1923 rows=856 width=4) (actual
time=0.072..24.614 rows=2393 loops=1)
-> Append (cost=0..1923 rows=856 width=4) (actual time=0.069..27
rows=2393 loops=1)
-> various scans on network_events
** Single subselect:
SELECT * FROM ip_info
WHERE ip IN (SELECT DISTINCT ip FROM network_events WHERE port = 2222
UNION
SELECT DISTINCT ip FROM host_events WHERE port = 2222);
Nested Loop (cost=2841..2856 rows=2 width=72) (actual time=55..106
rows=2349 loops=1)
-> Unique (cost=2841..2856 rows=2 width=72) (actual time=55..66
rows=2349 loops=1)
-> Sort (cost=2841..2841 rows=2 width=4) (actual time=55..58
rows=2401 loops=1)
-> Append (cost=1956..2841 rows=2 width=4) (actual time=29..50
rows=2401 loops=1)
-> Unique (cost=1956..1959 rows=2 width=4) (actual time=29..50
rows=2401 loops=1)
-> Sort
-> Result
-> Append
-> various scans on network_events
-> Unique (cost=869..871 rows=1 width=4) (actual time=2.9..3.3
rows=70 loops=1)
-> Sort
-> Result
-> Append
-> various scans on host_events
** The join:
SELECT distinct ip_info.*
FROM ip_info RIGHT JOIN network_events USING (ip)
RIGHT JOIN host_events USING (ip)
WHERE (network_events.port=2222 OR host_events.port=2222)
Unique (cost=9238..9367 rows=1965 width=72) (actual time=61..61 rows=52 loops=1)
-> Sort (cost=9238..9288 rows=1965 width=72) (actual time=61..61
rows=63 loops=1)
-> Hash Join (cost=850..9176 rows=1965 width=76) (actual
time=0..54 rows=2393 loops=1)
-> Nested Loop Left Join (cost=0..8205 rows=856 width=76)
(actual time=0..54 rows=2393 loops=1)
-> Append
-> various scans of network_events
-> Index Scan of ip_info (cost=0..7 rows=1 width=72) (actual
time=0..0 rows=1 loops 2393)
->Hash (cost=849..849 rows=459 width=4) (actual time=0..2 rows=72 loops=1)
-> Append
->various scans of host_events
On 2/1/07, Michael Artz <mlartz@xxxxxxxxx> wrote:
> > 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?
All the columns are indexed individually. The tables are completely
static, as I reload the whole DB with new data every day.
> 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
I guess that is the heart of my question. "name" is not very
selective (there are only 20 or so choices) however other columns are
fairly selective for certain cases, such as 'port'. When querying on
and unusual port, the query is very fast, and the single UNIONed
subselect returns quickly. When 'port' is not very selective (like
port = '80', which is roughly 1/2 of the rows in the DB), the dual
subselect query wins, hands-down.
And I have altered the statistics via the config file:
default_statistics_target = 100
Perhaps this should be even higher for certain columns?
> > 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.
Nah, that did very poorly.
> > 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?
hmm, I think so, but I'm not that good in reading the outputs. I'll
see if I can retype some of the interesting bits of the explain
analyze.
