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.92) (envelope-from ) id 1jGaUj-0006tp-MS for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2020 03:44:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jGaUi-0001Hn-Io for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2020 03:44:48 +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 1jGaUi-0001H0-9t for pgsql-hackers@lists.postgresql.org; Tue, 24 Mar 2020 03:44:48 +0000 Received: from mail-qt1-x843.google.com ([2607:f8b0:4864:20::843]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jGaUd-0007je-92 for pgsql-hackers@lists.postgresql.org; Tue, 24 Mar 2020 03:44:45 +0000 Received: by mail-qt1-x843.google.com with SMTP id m33so13920863qtb.3 for ; Mon, 23 Mar 2020 20:44:42 -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:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=/AeB7btR0ldPK5QSo8jyWxCVVJPwtZoX6+hT/OEZ2oo=; b=HrQgulLX8Ne2KH7v+Z6OM3M8oVOwuPKZHjNLa0S1RWXLCrYmCJ5VfPieDG/4NLDug/ a13pd+8W1MVRtTq8JMAYKY3sERx6R4S8BubDYm1v9vfz4ax8yPgxu7HRp2s9WVGUEa7J 0vjCKl9evDattKcj2yfmRvYxyH5ZO2BUo6FE70/O9NzoLUlfkNjoeop8vSsJAsTqC2Am bh5QwUom3wFOAhbDbNaj3RMOo022CK01zzRF4Q047XzCr9KCnLKvy+cHOBeoAuUceVwC c+FSWYyjlBxOzJIlHK+5eOmNNqStERvInT9V4P/wRlSTXmEw5/PIkQpMpYpInfiD+07/ 5Qwg== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=/AeB7btR0ldPK5QSo8jyWxCVVJPwtZoX6+hT/OEZ2oo=; b=rQCz9agNSsLDBco6rB3avP6D7Rbd5YB04mfxxfAoNvQ9dMAtzu4zG1rZeQ0Vr7zj1d FXqOR1Ba/oFhxwfFD86qEHs/iMT1NttsFPBGP4c3m4eHuSSkRPT9q7p58Zph3uyRnscG Hi/gBvG4wEJcuXw8llyh2jbSEdd8maQ1q1VpcaoOQfMegWtcNoiT0QqMNLpeUMbQpu9b CTGG2QwAFAo2YLj5FAu01Aad/o9MBer+o8kSrt/skGoyJ0oaPudkgRUpPM4rVobEZsMS VePvH2p+rP0xjq9qUTSfLYdg06TdaqpdRQWIL9JIR8IXBDVdzVSdjHwMywKh7dfPM4Jq UYsA== X-Gm-Message-State: ANhLgQ14E9wsVbIR5kkb/bgpkGfIQge2x1VpmFIRbb715JGb0ORxTrYx 557QMSA47olAqjN3EOCcULmEKw== X-Google-Smtp-Source: ADFU+vvPkIVPybgVLAGLX3zfGFgd0AZ/3rBtELhwz8ctkB6OrS8wA1DDZ4LM+qQ/r+ojqnl1/qnDsg== X-Received: by 2002:aed:34a3:: with SMTP id x32mr24827196qtd.306.1585021481453; Mon, 23 Mar 2020 20:44:41 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id 79sm12264317qkg.38.2020.03.23.20.44.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2020 20:44:40 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 492323006A7; Tue, 24 Mar 2020 00:44:38 -0300 (-03) Date: Tue, 24 Mar 2020 00:44:38 -0300 From: Alvaro Herrera To: James Coleman Cc: Tomas Vondra , Michael Paquier , Rafia Sabih , Peter Geoghegan , Simon Riggs , Shaun Thomas , Dmitry Dolgov <9erthalion6@gmail.com>, Alexander Korotkov , Tom Lane , PostgreSQL Developers , Andreas Karlsson Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort) Message-ID: <20200324034438.GA13003@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Mar-23, James Coleman wrote: > 4. nodeIncrementalSort.c ExecReScanIncrementalSort: This whole chunk > is suspect. I've mentioned previously I don't have a great mental > model of how rescan works and its invariants (IIRC someone said it was > about moving around a result set in a cursor). Regardless I'm pretty > sure this code just doesn't work correctly. I don't think that's the whole of it. My own vague understanding of ReScan is that it's there to support running a node again, possibly with different parameters. For example if you have a join of an indexscan on the outer side and an incremental sort on the inner side, and the values from the index are used as parameters to the incremental sort, then the incremental sort is going to receive ReScan calls for each of the values that the index returns. Sometimes the index could give you the same values as before (because there's a dupe in the index), so you can just return the same values from the incremental sort; but other times it's going to return different values so you need to reset the incremental sort to "start from scratch" using the new values as parameters. Now, if you have a cursor reading from the incremental sort and fetch all tuples, then rewind completely and fetch all again, then that's going to be a rescan as well. I agree with you that the code doesn't seem to implement that. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services