Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gZTe7-0000TA-Db for pgsql-performance@arkaria.postgresql.org; Wed, 19 Dec 2018 04:39:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gZTe6-0002r6-4K for pgsql-performance@arkaria.postgresql.org; Wed, 19 Dec 2018 04:39:46 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1gZTe5-0002qy-Qy for pgsql-performance@lists.postgresql.org; Wed, 19 Dec 2018 04:39:45 +0000 Received: from mail-pf1-x444.google.com ([2607:f8b0:4864:20::444]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gZTe2-0001Dn-Dw for pgsql-performance@lists.postgresql.org; Wed, 19 Dec 2018 04:39:45 +0000 Received: by mail-pf1-x444.google.com with SMTP id r136so2164776pfc.6 for ; Tue, 18 Dec 2018 20:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=2BBlbc0ER3JTBdWe13OMdeWMfJKmI2nrzAkKGCYent0=; b=QwsE2FlZjWZCHnIEA1+nRzm21O8lKvOTdpW1CCC2/BhUGVpA2af4vA89an+NgCm1Gm Hp1SqpTTiLU9nHWakWf0qMRp9WIxLyES0KU0klbCFd2Rqe1LapGJzJeB/jVzKb+ZBfNy /Rj6urzkGTFyPOakEVwmpPjMcAU4LjzrHozfA3rzBsBD13Ien3eiKYHe7HG7G7xBFM6l RbJZ07LGlfz7fOZqKoZkgoE0r7HwQFWrBUk8JxcXTih8L+HJeWXuldsmXSByjM0e/s+d ut86HEHfwFdpmsKZf85C5xFLZIed1YdZE3RQjOrfsNlnfhG56DLBAjKfLjrMKROmG3/I rX6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=2BBlbc0ER3JTBdWe13OMdeWMfJKmI2nrzAkKGCYent0=; b=VZM07KRgZm2SQXt6DKGFJZGcvo0julPITS5fW9P+8kECkbGk5N3479aVQgX+e38WUz Z3Fu0vP3g7SlNEg6JDuzCoYhyLMZMQn8zytoPeMe38CjOxQRUM/SxmREajDbgL4BAmXJ gES/gDZTnrhRxwEzsP/F1cbZ6OEzdfl3xJWHHP51hYgs80cw0rG8584SnHOfgvQGqh/l jrXPg2Ueoc6wKXNyjYEJn7O1JLcUynrLiKlF7UsWVJrqMnZlaL8ygw78njj3dd+iQgDI BFnP5xib92g3/WRegkiVo29t/DVBeLDluExPI1kna/JAGeUu/+1kB0RicrJYocht4gvs xtjw== X-Gm-Message-State: AA+aEWbQ9FRQ2+RIET80VKL1yoWnyvOxbiqzC1anDJrlCbOhbz6uOBoZ CZe2/tDZ6SyFDmO8pAJrBBcq14YD X-Google-Smtp-Source: AFSGD/XgJKMuEzOTskhtcbMfmnFlyYJye5VqtklIZEJWsGxG+hvcNugBt2PfoL/FeUjZMme5alcmxg== X-Received: by 2002:a63:e156:: with SMTP id h22mr18246381pgk.255.1545194378178; Tue, 18 Dec 2018 20:39:38 -0800 (PST) Received: from Eshu.local (cpe-76-176-9-104.san.res.rr.com. [76.176.9.104]) by smtp.gmail.com with ESMTPSA id w184sm18814342pgd.34.2018.12.18.20.39.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 20:39:37 -0800 (PST) From: Patrick Mulrooney To: pgsql-performance@lists.postgresql.org Subject: Increasing parallelism of queries while using file fdw and partitions Message-ID: Date: Tue, 18 Dec 2018 20:39:36 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Wondering if anyone had any thoughts on how to tweak my setup to get it to read many files at once instead of one at a time when using file fdw and partitions. We have a bunch of data tied up in files (each file > 4M rows, 5,000+ files per year) that I would like to be able to query directly using FDW. The files are genomic VCF format and I find that vcf_fdw ( https://github.com/ergo70/vcf_fdw ) works really well to read the data. We only want to be able to search the data as quickly as possible, no updates / deletes / ... I gave an example below of the basic setup and the output of explain analyze. I get the same performance if I setup the table such that the thousands of files end up in one non-partitioned table or setup each file as it's own partition of the table. I have tried increasing ( / decreasing ) the worker threads and workers, but don't see any change in the number of files open at any given time. I tried reducing the cost of parallel queries to force them to run, but can't get them to kick in. Any ideas or anything I can try? Thanks! Pat PostgreSQL: PostgreSQL 10.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit Multicorn: 1.3.5 VCF_FDW ( https://github.com/ergo70/vcf_fdw ) : 1.0.0 CREATE DATABASE variants; CREATE EXTENSION multicorn; CREATE SERVER multicorn_vcf FOREIGN DATA WRAPPER multicorn OPTIONS (wrapper 'vcf_fdw.VCFForeignDataWrapper'); CREATE SCHEMA vcf; CREATE TABLE vcf.variants ( ..., species text, ... ) PARTITION BY LIST ( species ); CREATE FOREIGN TABLE vcf.human ( ... ) SERVER multicorn_vcf OPTIONS (basedir '/path', species 'human', suffix '.vcf.gz'); ALTER TABLE vcf.variants ATTACH PARTITION vcf.human FOR VALUES IN ( 'human' ); CREATE FOREIGN TABLE vcf.dog ( ... ) SERVER multicorn_vcf OPTIONS (basedir '/path', species 'dog', suffix '.vcf.gz'); ALTER TABLE vcf.variants ATTACH PARTITION vcf.dog FOR VALUES IN ( 'dog' ); CREATE FOREIGN TABLE vcf.cat ( ... ) SERVER multicorn_vcf OPTIONS (basedir '/path', species 'cat', suffix '.vcf.gz'); ALTER TABLE vcf.variants ATTACH PARTITION vcf.cat FOR VALUES IN ( 'cat' ); * My real data repeats this 1000+ more times EXPLAIN ( ANALYZE, BUFFERS ) SELECT * FROM vcf.variants WHERE chrom = '1' AND pos = 10120 LIMIT 1000; On my real data I get the following results: -------------------------- QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Limit (cost=20.00..352020.00 rows=1000 width=347) (actual time=445.548..101709.307 rows=20 loops=1) -> Append (cost=20.00..3555200000.00 rows=10100000 width=347) (actual time=445.547..101709.285 rows=20 loops=1) -> Foreign Scan on dog (cost=20.00..3520000.00 rows=10000 width=352) (actual time=198.653..198.654 rows=0 loops=1) Filter: ((chrom = '1'::text) AND (pos = 10120)) -> Foreign Scan on cat (cost=20.00..3520000.00 rows=10000 width=352) (actual time=111.840..111.840 rows=0 loops=1) Filter: ((chrom = '1'::text) AND (pos = 10120)) -> Foreign Scan on human (cost=20.00..3520000.00 rows=10000 width=352) (actual time=135.050..138.534 rows=1 loops=1) Filter: ((chrom = '1'::text) AND (pos = 10120)) ... repeats many more times for each partition Planning time: 613.815 ms Execution time: 101873.880 ms (2024 rows)