Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEHqz-0003rW-4r for pgsql-performance@arkaria.postgresql.org; Mon, 13 Nov 2017 16:44:57 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eEHqy-0006Iu-Of for pgsql-performance@arkaria.postgresql.org; Mon, 13 Nov 2017 16:44:56 +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_2) (envelope-from ) id 1eEHqy-0006Il-Bi for pgsql-performance@postgresql.org; Mon, 13 Nov 2017 16:44:56 +0000 Received: from mail-it0-x232.google.com ([2607:f8b0:4001:c0b::232]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eEHqw-0005q9-0J for pgsql-performance@postgresql.org; Mon, 13 Nov 2017 16:44:55 +0000 Received: by mail-it0-x232.google.com with SMTP id r127so10065954itb.5 for ; Mon, 13 Nov 2017 08:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xhcEGlUlmE2zVBBgARpCEJOotRDIcuOhvrWedRJeDyU=; b=mbKD6SWsvWPH9BiCg9XiZDKIKLdMCdbCCP7g7yihxkNDhFxC3I+Awr9HG/n6ZBuoIK 9EGCqYWfE+ENFHIt1X3UaAARkFXogQcsEyfUpjwC0sr84DDxkVbwdTtyu0WLufeH6Aos SGH1I8Bg4Y4ghTawKVNRoUluA6v6a8FYG8Dkg9WbN9r84wN1OUtuvRILLMOQHzEkr9S5 PXvQwoy2Ee3qOc943F4F06W3qLFPo9rl6Z5JgDdh7gbUHOdLGtvfuU6Hl2E7mgqMkini BVbXD6ATff+6DWJZMXpnNAWY++DfSSrRoeZ5CwZ1IHS+gYrhtWpafgfyiRKMjSFoJrJL E3Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xhcEGlUlmE2zVBBgARpCEJOotRDIcuOhvrWedRJeDyU=; b=VUm1KuWNZ7ccUkBZe5zYLj/FqqCiG0cgTuE1qr0S95dw5xHGjkaZqzLuNWcxCRkZhV VNjwkGkUf7CQvpvmuMvIcKEXmRKIfeveXJJ6imxTUCzXFgfGCaFzvUSlDhxaLVXhi/3/ lvGQARgmA8LfRpcS1uT9yaOxqu1i8M2vO/MjrzidpInxNdpVb4x2qmPphsQ4ruVeA6Aq iTFp+5PbyjSES4feX2vjWWlb/mKuHflrzvAKq0tByNAG2wZ4ChgftfyFfNBWvRFmUxr0 tVRAgwNvM0f7qVLhuuU9q9oFm+TVIGn0mW3rBhAOmIhCeX8YQ14DBRMNXBP5E4EgUsZ0 ZbUw== X-Gm-Message-State: AJaThX5280oiwSRK0Ac1coZRwlQf4p2R/RimIIUbYZcaFo1OKB3oK5F3 t+2wzI/c+hT9tGKNHNX7XsJ4iQ== X-Google-Smtp-Source: AGs4zMbbb9QHS5Am5W+YMw0VK0hxoA+3l9hDFSz8YbyKluXB0dfFxcsnPxRpOjNiRbXqp27ctw9zjw== X-Received: by 10.36.139.69 with SMTP id g66mr10955802ite.71.1510591491745; Mon, 13 Nov 2017 08:44:51 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id j67sm2169044iod.12.2017.11.13.08.44.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 08:44:50 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id 189so21269988iow.10 for ; Mon, 13 Nov 2017 08:44:50 -0800 (PST) X-Received: by 10.107.173.71 with SMTP id w68mr11351351ioe.57.1510591490066; Mon, 13 Nov 2017 08:44:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.209.7 with HTTP; Mon, 13 Nov 2017 08:44:49 -0800 (PST) X-Originating-IP: [88.211.72.10] From: Oliver Mattos Date: Mon, 13 Nov 2017 16:44:49 +0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Query planner gaining the ability to replanning after start of query execution. To: pgsql-performance@postgresql.org Content-Type: text/plain; charset="UTF-8" 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 I am interested in giving the query planner the ability to replan (or re-rank plans) after query execution has begun, based on the progression of the query so far. Example use case: * A LIMIT 1 query is planned using an expensive scan which the planner expects to return a large number of results, and to terminate early. The reality is the query actually produces no results, and the scan must run to completion, potentially taking thousands of times longer than expected. * If this plans costs were adjusted mid-execution to reflect the fact that the scan is producing far fewer rows than expected, then another query plan might come out ahead, which would complete far faster. Has this been done before? Are there any pitfalls to beware of? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance