Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oG3NU-00047K-IV for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jul 2022 19:04:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oG3NS-0008Ha-L5 for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Jul 2022 19:04:26 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oG3NS-0008HG-9v for pgsql-hackers@lists.postgresql.org; Mon, 25 Jul 2022 19:04:26 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oG3NP-000656-Qc for pgsql-hackers@postgresql.org; Mon, 25 Jul 2022 19:04:25 +0000 Received: by mail-pl1-x62e.google.com with SMTP id x1so9501386plb.3 for ; Mon, 25 Jul 2022 12:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=EPDm0lhU3cUm/YDvdJx9sQMhQmhEh3xiztihehkXkEY=; b=gTBavrdhtVy+u7n1X+laIe2Vy8/kP8/VasSnw5jxfTzLqUbhKu4GwHOixyoA+DVvOT tTJBRjyrzWm7uwkfMfC+AUWwdMjseKlTOEqpSKeJGb1XPYn3o5ZlM/+XlqiIPJ2sJ+0i 5cxSb47RIub+sjb0cO+ymoreN3SbUwp3Bdr9fd1pAeaVXByXUDFJQYEGFq5FECblrXip LiI/FyaDf2QxlSOMlRoRViQ94poPgxJNgZxF1J8JJpsQ1wsT0afx+RxlwdPO5ymH3mK3 F7eAVAFyqmgKErB4BsUIsXrB3PFZOi2gtLOKDi6yH2U219n6uBDyZf/x6fx4E43T2kIq HNYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=EPDm0lhU3cUm/YDvdJx9sQMhQmhEh3xiztihehkXkEY=; b=cREVacuvWz8S8ROuHfNdITisawpC7pGvTM5zaw5cLhflDSJX4CtpzzVdo9RtlXS8wz 670IRuiOl1NIoU/od69d/pkioqwpSRlH4d1vdh077EIVVGiPE4/gSBSLVI58vHf2ufcS nQXUX5miDfamV5m95BpgmEKwSEKOF9buGfNxBGND6RjGaBpXobRlsqia+EGyW7Um36OO 9U1pBOdHaN/4+f4QOp27h+NUoU4XbVrsQCmKPONI3rXtDlgIYa0LmEdJrZNebpfCAOff m9rX6rIFDEuNmgKEQAHrKccgF9eJX4WhUkPNsIl81Qaw9cynjtdtyO7+Aq5BoAkUahcY 0agg== X-Gm-Message-State: AJIora/oGN527EO5Nandd5Duz+RE1/pcXmSGqGLbvr2zZPWG+VWytu9N uSwrIeatPo6RXLl1MTAk9SM= X-Google-Smtp-Source: AGRyM1vGq4sc2EQRHaYULl++7x2rF71vndP/NutTx/yjbYr+JFo1OQPwJuteVfFP+Q+B9pw3Aokpcg== X-Received: by 2002:a17:90b:1b52:b0:1f2:9722:fe31 with SMTP id nv18-20020a17090b1b5200b001f29722fe31mr9909534pjb.52.1658775862386; Mon, 25 Jul 2022 12:04:22 -0700 (PDT) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id u129-20020a627987000000b00525521a288dsm9943862pfc.28.2022.07.25.12.04.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Jul 2022 12:04:21 -0700 (PDT) Date: Mon, 25 Jul 2022 12:04:19 -0700 From: Nathan Bossart To: Andres Freund Cc: John Naylor , pgsql-hackers@postgresql.org Subject: Re: optimize lookups in snapshot [sub]xip arrays Message-ID: <20220725190419.GA4095199@nathanxps13> References: <20220713170950.GA3116318@nathanxps13> <20220715200857.nm2gc4weixwlwbnx@awork3.anarazel.de> <20220717035957.GA3631071@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220717035957.GA3631071@nathanxps13> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Jul 16, 2022 at 08:59:57PM -0700, Nathan Bossart wrote: > On Fri, Jul 15, 2022 at 01:08:57PM -0700, Andres Freund wrote: >> I wonder if we additionally / alternatively could use a faster method of >> searching the array linearly, e.g. using SIMD. > > I looked into using SIMD. The patch is attached, but it is only intended > for benchmarking purposes and isn't anywhere close to being worth serious > review. There may be a simpler/better way to implement the linear search, > but this seemed to work well. Overall, SIMD provided a decent improvement. > I had to increase the number of writers quite a bit in order to demonstrate > where the hash tables began winning. Here are the numbers: > > writers head simd hash > 256 663 632 694 > 512 530 618 637 > 768 489 544 573 > 1024 364 508 562 > 2048 185 306 485 > 4096 146 197 441 > > While it is unsurprising that the hash tables perform the best, there are a > couple of advantages to SIMD that might make that approach worth > considering. For one, there's really no overhead (i.e., you don't need to > sort the array or build a hash table), so we can avoid picking an arbitrary > threshold and just have one code path. Also, a SIMD implementation for a > linear search through an array of integers could likely be easily reused > elsewhere. From the discussion thus far, it seems there is interest in optimizing [sub]xip lookups, so I'd like to spend some time moving it forward. I think the biggest open question is which approach to take. Both the SIMD and hash table approaches seem viable, but I think I prefer the SIMD approach at the moment (see the last paragraph of quoted text for the reasons). What do folks think? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com