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 1hBll7-0007Mo-Ik for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Apr 2019 19:41:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hBll6-0004Ui-4z for pgsql-hackers@arkaria.postgresql.org; Wed, 03 Apr 2019 19:41:16 +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 1hBll5-0004Ub-Sj for pgsql-hackers@lists.postgresql.org; Wed, 03 Apr 2019 19:41:15 +0000 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBll0-0001ni-Kn for pgsql-hackers@postgresql.org; Wed, 03 Apr 2019 19:41:12 +0000 Received: by mail-wm1-x344.google.com with SMTP id a184so157254wma.2 for ; Wed, 03 Apr 2019 12:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ZYQIoPzLG/D4TvNtrWiEiluG3z71M7OFtjtdEo9DNGk=; b=f6sehNSb7uuo6k9IRzszTkl+mRbliAhq7ItU56LsKTyvcl36ZepRGVrSQJPLkVL1FW WWm4XmX3uNERHuD0V9wIwV32aLVCTgW0K+Q2Co8BG290flgdL7dAoZ2Kc5IRHYL756fv UWfTOH+5rqkw1canjN7t0D9Vc0pkBBMBZ9uxRqZNagQNHUFyRHfqnBmwCLyJwJaegL27 uNr/VkTx+LnCM0hHZclqicmAz00nV5tP06cdtKvtg/2gTdA5UZlfHAazweNMcWsjX1Bc Dxzm+odchgOvFPVfPO7ko3knIV1SGlOUpWwBxCgi/dVpcmnvtiK5VieINS11sYskTTNG RSpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ZYQIoPzLG/D4TvNtrWiEiluG3z71M7OFtjtdEo9DNGk=; b=QgPYv/1Oyk+O9P15iiBgmX65YptRkN1Dca0d87jvUfgb2t5NX+VjNYgshLf5rawuVQ SgvomBS4KdNAIty2EfV7IVj+UnSPabRR5TYXBwHujDGh18ilTbvt925Jr7JpM2hYeart 3O+jKROlkWI8ig+0suxioClH9fT4wjfmHf6fUj7PZm5cT8vabnl0Oo7HaCtKB8hFrI8O 4Sp8CM4RqGX/avKQpA06PKB9F8QMNGQVVLd4eA46YRvPCFwSMVtc8q/17ztAPMwtJ869 rQ+e/Mge2DIjFGZ/6hjrWLaTw/J9TP7wLOCzESoNUNQdwqSj3oCRt5iGMX1yv9nuXiWv uylA== X-Gm-Message-State: APjAAAVddAfKICM77nbU76p9l5CLur0Yh0pX0fTKdgT3uMQsvE9Wfbof C+5Pzr/OyNJ2+8vxgTlraQDJUA== X-Google-Smtp-Source: APXvYqweiqVjqtwd/mvhRO8MXyQCKeJTxI4FdkFpqlJ271XAzzpJUyMz3qoMTRqqoVtswCZDXlj/dg== X-Received: by 2002:a1c:14:: with SMTP id 20mr1125962wma.66.1554320468705; Wed, 03 Apr 2019 12:41:08 -0700 (PDT) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id z17sm17308779wmc.7.2019.04.03.12.41.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Apr 2019 12:41:00 -0700 (PDT) Date: Wed, 3 Apr 2019 21:40:59 +0200 From: Tomas Vondra To: Tom Lane Cc: Surafel Temesgen , David Steele , Michael Paquier , Robert Haas , andrew@tao11.riddles.org.uk, PostgreSQL Hackers Subject: Re: FETCH FIRST clause WITH TIES option Message-ID: <20190403194059.yqtuuwtsipq2vknh@development> References: <20190204052857.GP29064@paquier.xyz> <20190329005648.GA1136@development> <20190331001446.GA10804@development> <20190403190257.44fxttkpo4yopp3l@development> <32413.1554318485@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <32413.1554318485@sss.pgh.pa.us> User-Agent: NeoMutt/20180716-1432-ae87f8 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Apr 03, 2019 at 03:08:05PM -0400, Tom Lane wrote: >Tomas Vondra writes: >> I've tried to fix the merge conflict (essentially by moving some of the >> code to adjust_limit_rows_costs(), but I'm wondering if the code added to >> create_limit_path is actually correct >> ... >> Firstly, this seriously needs some comment explaining why we do this. > >I've not looked at this patch, but TBH I wonder why it is touching >planner rowcount estimation at all. I find it doubtful either that >a correction for WITH TIES would be significant in most use-cases, >or that we could estimate it accurately if it was significant. >It certainly doesn't seem like something that needs to be messed >with in v1 of the feature. > FWIW it was me who suggested to tweak the cardinality estimation this way, but if we want to leave it out from v1, I'm OK with that. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services