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 1itqK9-0007Ql-KE for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2020 09:59:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1itqK8-0005xo-BH for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2020 09:59:52 +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 <9erthalion6@gmail.com>) id 1itqK8-0005xh-0F for pgsql-hackers@lists.postgresql.org; Tue, 21 Jan 2020 09:59:52 +0000 Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1itqK2-0001h3-RK for pgsql-hackers@postgresql.org; Tue, 21 Jan 2020 09:59:51 +0000 Received: by mail-wr1-x441.google.com with SMTP id j42so2375879wrj.12 for ; Tue, 21 Jan 2020 01:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+/6hQO4Svk8skneXeOY0SBSy9bwzhqreFA5OACWGJyw=; b=LBhcBnarj4fYlcYIz/UaHtRbSbozN5O0oAD3gIbC29IiAawA/B5KQ2Nmvfygqeo0xo rq2OwMxJHJr/h6R3bsEI93KIM4F6e2LtsmNgCZqnT+GcgpPbdFDMjVgzMZcd93nWGo3Z dbprXkdUdRho9v5uWmgH/+DtemNa3HQGOfuHf2657b0DPypAvaR5zx3htTTA2uqa1rKu 6oGCct8vnurt0DzINEfotxMHlqaYVeFci1ho7D0V4UPTDvLc7JXj5RxVWtg1ANAemRYe b4zyJMVXNRqhvs3IsbU8OIQH+hF5MswEX4kha/XTANb4RoOwtS+Cp1H31d34vdW2iiqq ZBMQ== 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; bh=+/6hQO4Svk8skneXeOY0SBSy9bwzhqreFA5OACWGJyw=; b=E8WZ2JdY/qvO1Y+E/tJzDYnPPNrrmPrBH4cBXJVKGpPeOtlpZ2Xp28y3Z3OHRggp0Q sU7aMeLKl3g2dJ+HNaaHr7w+mKHYPbWnfVSA/9uXfKkcBHXNEYd54beEN0/XSwvFe8d3 9nu9Tpa1vNdln9jKRfSHredekx066dIxBB5bI9TTMh7djGSrzIyKWXgI6Dw2ks411dD0 aQNp9Owo80BsckGq5dtKPkMXKnkYT+FmknjZsXLUcLFw6OyTotEUWQO2BmBc04324CbQ Ssy6H9bvQSdywSzmmKObrev6rMDZ34OhkZkQRTclNLUdfvRgPxILQ5p1o5Ee9GunSJ9f NGvA== X-Gm-Message-State: APjAAAXDUdCpf+yCI/IzJLoIe59OscvD9uu2p2q6HpdqcbYiyOZKGTMd cODZq2ef8Az4cTrfM5i44is= X-Google-Smtp-Source: APXvYqy45l54ONv8w/K2TVAHuyWAgwoonB0QH+OV+tOqhgTHpdGWQzIdNfwq2beUjx18Zmp/9EoXDA== X-Received: by 2002:adf:f7c4:: with SMTP id a4mr4167901wrq.332.1579600785658; Tue, 21 Jan 2020 01:59:45 -0800 (PST) Received: from localhost ([185.85.220.193]) by smtp.gmail.com with ESMTPSA id y22sm3122278wma.35.2020.01.21.01.59.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2020 01:59:44 -0800 (PST) Date: Tue, 21 Jan 2020 11:00:08 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Peter Geoghegan Cc: Jesper Pedersen , Floris Van Nee , David Rowley , Tomas Vondra , Kyotaro Horiguchi , Alvaro Herrera , Thomas Munro , James Coleman , Rafia Sabih , Jeff Janes , Bhushan Uparkar , PostgreSQL-development , Alexander Korotkov Subject: Re: Index Skip Scan Message-ID: <20200121100008.bsrrp3rtsfvv3ntq@localhost> References: <1e59d800b38141c5af2ad3a64cf9758e@opammb0562.comp.optiver.com> <802e46fa-dc2c-4c32-e55b-884e04aa7f12@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Mon, Jan 20, 2020 at 05:05:33PM -0800, Peter Geoghegan wrote: > > I suggest that you find a way to add assertions to code like > _bt_readpage() that verify that we do in fact have the buffer content > lock. Actually, there is an existing assertion here that covers the > pin, but not the buffer content lock: > > static bool > _bt_readpage(IndexScanDesc scan, ScanDirection dir, OffsetNumber offnum) > { > > ... > > /* > * We must have the buffer pinned and locked, but the usual macro can't be > * used here; this function is what makes it good for currPos. > */ > Assert(BufferIsValid(so->currPos.buf)); > > You can add another assertion that calls a new utility function in > bufmgr.c. That can use the same logic as this existing assertion in > FlushOneBuffer(): > > Assert(LWLockHeldByMe(BufferDescriptorGetContentLock(bufHdr))); > > We haven't needed assertions like this so far because it's usually it > is clear whether or not a buffer lock is held (plus the bufmgr.c > assertions help on their own). The fact that it isn't clear whether or > not a buffer lock will be held by caller here suggests a problem. Even > still, having some guard rails in the form of these assertions could > be helpful. Also, it seems like _bt_scankey_within_page() should have > a similar set of assertions. Thanks for suggestion. Agree, we will add such guards. It seems that in general I need to go through the locking in the patch one more time, since there are some gaps I din't notice/didn't know about before. > BTW, there is a paper that describes optimizations like loose index > scan and skip scan together, in fairly general terms: "Efficient > Search of Multidimensional B-Trees". Loose index scans are given the > name "MDAM duplicate elimination" in the paper. See: > > http://vldb.org/conf/1995/P710.PDF > > Goetz Graefe told me about the paper. It seems like the closest thing > that exists to a taxonomy or conceptual framework for these > techniques. Yes, I've read this paper, as it's indeed the only reference I found about this topic in literature. But unfortunately it's not much and (at least from the first read) gives only an overview of the idea.