Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZUE0k-0003zk-33 for pgsql-performance@arkaria.postgresql.org; Tue, 25 Aug 2015 13:11:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZUE0j-0004Qx-H5 for pgsql-performance@arkaria.postgresql.org; Tue, 25 Aug 2015 13:11:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZUE0i-0004QE-Oc for pgsql-performance@postgresql.org; Tue, 25 Aug 2015 13:11:32 +0000 Received: from e-mailfilter02.sunet.se ([2001:6b0:8:2::202]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZUE0e-0005Yd-WD for pgsql-performance@postgresql.org; Tue, 25 Aug 2015 13:11:31 +0000 Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t7PDBQHO011926 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 25 Aug 2015 15:11:26 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.7/8.14.7) with ESMTP id t7PDBNBN006303 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Aug 2015 13:11:26 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1440508286; bh=/DfglAE/S6/CRysoTY3c6cvP41OUH9U7v3SuuRUmAXo=; h=Date:From:To:Subject; b=EtsfGM5LmZm6zp3qSq4gw6KPqYZ60KOEpxr5VSGXfFjWwNLZeTD1tkSuuju8MY5Xi rasBea464MinNi5yeOIBBEuK3bwovJdyLucO5lKXXjvPWdmpiBoAdOmjZvPMRSkvF7 vN17ziSWb+VqKx/9U/USW3q6/DP65N4g4BeQC+jk= X-Footer: bm9yZHUubmV0 Received: from pyrite ([130.225.198.224]) (authenticated user htj@nordu.net) by kerio.nordu.net (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for pgsql-performance@postgresql.org; Tue, 25 Aug 2015 15:11:22 +0200 Date: Tue, 25 Aug 2015 15:11:43 +0200 (CEST) From: Henrik Thostrup Jensen X-X-Sender: htj@pyrite To: pgsql-performance@postgresql.org Subject: Gist indexing performance with cidr types Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Scanned-By: CanIt (www . roaringpenguin . com) X-Scanned-By: MIMEDefang 2.74 on 109.105.111.32 X-Spam-Score: undef - 109.105.110.42 is whitelisted. X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aP91bqM8 - 2380982e2518 - 20150825 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter02.sunet.se: 109.105.110.42 is neither permitted nor denied by domain htj@nordu.net) receiver=e-mailfilter02.sunet.se; client-ip=109.105.110.42; envelope-from=; helo=smtp1.nordu.net; identity=mailfrom X-Pg-Spam-Score: -4.3 (----) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Hi I'm trying to get a query to run fast enough for interactive use. I've gotten some speed-up, but still not there. It is for a tool called IRRExplorer (http://irrexplorer.nlnog.net/) that correlates IP routes between Internet Route Registries and real-world routing information. We landed on PostgreSQL largely due to indexing of the cidr type with gist indexing. * Preliminaries: The query is about getting data from this table: irrexplorer=> \d routes Table "public.routes" Column | Type | Modifiers -----------+---------+----------- route | cidr | not null asn | bigint | not null source_id | integer | not null Indexes: "unique_entry" UNIQUE CONSTRAINT, btree (route, asn, source_id) "route_gist" gist (route inet_ops) Check constraints: "positive_asn" CHECK (asn > 0) Foreign-key constraints: "routes_source_id_fkey" FOREIGN KEY (source_id) REFERENCES sources(id) Complete DDL: https://github.com/job/irrexplorer/blob/master/data/schema.sql Data set: 125 MB on disk, 2.3 million rows. Running stock PostgreSQL 9.4.4 on Ubuntu 14.10 (hosted on VMWare on OS X) Have done VACUUM, ANALYZE, and checked memory settings, and tried to increase work_mem, but with no success. The issue seems cpu bound (100% cpu load during query). * Query When a user inputs an AS number a simple match on the asn column will return the stuff relevant. However, the interesting thing to display is conflicting/rogue routes. This means matching routes with the && operator to find all covered/covering routes. This would look something like this: SELECT rv.route, rv.asn, rv.source FROM routes_view rv LEFT OUTER JOIN routes_view r ON (rv.route && r.route) WHERE rv.route && r.route AND r.asn = %s While this is fairly fast if the initial set of routes is relatively small (<100) it runs with a second or so, but if the number of routes matching the asn is large (>1000), it takes quite a while (+30 seconds). Explain analyze link: http://explain.depesz.com/s/dHqo I am not terribly good at reading the output, but it seem most of the time is actually spend on the bitmap scan for the gist index. It there another type of indexing that would behave better here? Since there often identical routes in the initial set of routes (from the AS number matching), I tried reducing the initial set of matching routes: ORDER BY rv.route; SELECT rv.route, rv.asn, rv.source FROM (SELECT DISTINCT route FROM routes_view WHERE asn = %s) r LEFT OUTER JOIN routes_view rv ON (r.route && rv.route) This often cuts the set of initial matching routes by 25-50%, and cuts a similar amount of time from the query time. Explain analyze link: http://explain.depesz.com/s/kf13 I tried further reducing the routes to the minimal set: WITH distinct_routes AS (SELECT DISTINCT route FROM routes_view WHERE asn = %s) SELECT route FROM distinct_routes EXCEPT SELECT r1.route FROM distinct_routes r1 INNER JOIN distinct_routes r2 ON (r1.route << r2.route); But typically only yields 10-20% reduction of the inital route set, and adds query complexity (putting the above in a CTE/WITH seems to make the query significantly slower for some reason). The main issue seem to be with the gist bitmap index. Is there a better way to approach this style of query? Best regards, Henrik -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance