Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TfuJP-0003Ma-LH for pgsql-performance@arkaria.postgresql.org; Tue, 04 Dec 2012 15:21:31 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TfuJO-0006Ig-Ev for pgsql-performance@arkaria.postgresql.org; Tue, 04 Dec 2012 15:21:30 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TfuJN-0006IP-K7 for pgsql-performance@postgresql.org; Tue, 04 Dec 2012 15:21:29 +0000 Received: from li188-192.members.linode.com ([178.79.132.192] helo=foo.me.uk) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TfuJK-0007ll-PQ for pgsql-performance@postgresql.org; Tue, 04 Dec 2012 15:21:29 +0000 Received: from webmail.cantabcapital.com ([212.44.17.222] helo=CCPPRT350008) by foo.me.uk with esmtpa (Exim 4.71) (envelope-from ) id 1Tfucl-00019e-Ej for pgsql-performance@postgresql.org; Tue, 04 Dec 2012 15:41:32 +0000 From: To: References: <092a01cdd230$ff6143c0$fe23cb40$@foo.me.uk> In-Reply-To: <092a01cdd230$ff6143c0$fe23cb40$@foo.me.uk> Date: Tue, 4 Dec 2012 15:21:17 -0000 Message-ID: <093301cdd233$057a2b30$106e8190$@foo.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE7bKfasxp9xMk0I5yxURpgMQ+bBJktjBTA Content-Language: en-gb X-SA-Exim-Connect-IP: 212.44.17.222 X-SA-Exim-Mail-From: pscott@foo.me.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on foo.me.uk X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 Subject: Re: Slow query: bitmap scan troubles X-SA-Exim-Version: 4.2.1 (built Sat, 07 Nov 2009 20:03:47 +0000) X-SA-Exim-Scanned: Yes (on foo.me.uk) X-Pg-Spam-Score: -1.9 (-) 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 Bad form to reply to yourself I know but just check-reading that for the third time I noticed two mistakes - The box has 128Gb of ram, not 512Mb - There is an additional constraint on the position_effect table (though I don't think it matters for this discussion): CONSTRAINT cons_pe_trade FOREIGN KEY (id_trade) REFERENCES trade (id) Sorry to clog your inboxes further! Regards, Philip -----Original Message----- From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of postgresql@foo.me.uk Sent: 04 December 2012 15:07 To: pgsql-performance@postgresql.org Subject: [PERFORM] Slow query: bitmap scan troubles Hi guys (and girls) I've been banging my head over this for a few days now so if any of you kind souls could take a minute to take a look at this I would be eternally grateful. I have a pretty straightforward query that is very slow by default, and about 70 times faster when I set enable_bitmapscan=off. I would like to convince the planner to use my lovely indexes. The scenario is this; I have two tables, trade and position_effect. A trade is a deal we do with somebody to exchange something for something else. It has a time it was done, and is associated with a particular book for accounting purposes. A position effect records changes to our position (e.g. how much we have) of an particular asset. One trade can many position effects (usually only 1,2 or 3) For example, I do a trade of USD/GBP and I get two position effects, +1000 GBP and -1200USD SCHEMA: ------- The actual schema is a bit more complicated but I will put the important parts here (if you think it important, the full schema for the two tables is here: http://pastebin.com/6Y52aDFL): CREATE TABLE trade ( id bigserial NOT NULL, time_executed timestamp with time zone NOT NULL, id_book integer NOT NULL, CONSTRAINT cons_trade_primary_key PRIMARY KEY (id), ) CREATE INDEX idx_trade_id_book ON trade USING btree (id_book, time_executed, id); CREATE TABLE position_effect ( id bigserial NOT NULL, id_trade bigint NOT NULL, id_asset integer NOT NULL, quantity double precision NOT NULL, CONSTRAINT cons_pe_primary_key PRIMARY KEY (id_trade, id_asset), ) SETUP: ------ These tables are relatively large (~100 million rows in position effect). The box is a pretty beastly affair with 512Mb of ram and 4x10 2Ghz cores. The postgres configuration is here: http://pastebin.com/48uyiak7 I am using a 64bit postgresql 9.2.1, hand compiled on a RedHat 6.2 box. QUERY: ------ What I want to do is sum all of the position effects, for a particular asset while joined to the trade table to filter for the time it was executed and the book it was traded into: SELECT sum(position_effect.quantity) FROM trade, position_effect WHERE trade.id = position_effect.id_trade AND position_effect.id_asset = 1837 AND trade.time_executed >= '2012-10-28 00:00:00' AND trade.id_book = 41 In this case there are only 11 rows that need to be summed. If I just let postgres do its thing, that query takes 5000ms (Which when multiplied over many books and assets gets very slow). I think this is because it is bitmapping the whole position_effect table which is very large. If I disable bitmap scans: set enable_bitmapscan = off; The query takes 43ms, and properly uses the indexes I have set up. Slow version with bitmapscan enabled: http://explain.depesz.com/s/6I7 Fast version with bitmapscan disabled: http://explain.depesz.com/s/4MWG -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance