On Mon, Aug 8, 2022 at 12:17 PM John Naylor <john.nay...@enterprisedb.com> wrote: > > On Sun, Aug 7, 2022 at 4:25 AM Nathan Bossart <nathandboss...@gmail.com> > wrote: > > > > [v8] > > Okay, I think it's basically in good shape. Since it should be a bit > faster than a couple versions ago, would you be up for retesting with > the original test having 8 to 512 writers? And also add the const > markers we discussed upthread? Aside from that, I plan to commit this > week unless there is further bikeshedding.
I quickly reviewed v8 patch set, few comments: 1) pg_lfind32 - why just uint32? If it's not possible to define functions for char, unsigned char, int16, uint16, int32, int64, uint64 and so on, can we add a few comments around that? Also, the comments can talk about if the base type or element data type of array or data type of key matters to use pg_lfind32. 2) I think this is not just for the remaining elements but also for non-USE_SSE2 cases. Also, please specify in which cases we reach here for USE_SSE2 cases. + /* Process the remaining elements the slow way. */ 3) Can pg_lfind32 return the index of the key found, for instance to use it for setting/resetting the found element in the array? + * pg_lfind32 + * + * Returns true if there is an element in 'base' that equals 'key'. Otherwise, + * returns false. + */ +static inline bool +pg_lfind32(uint32 key, uint32 *base, uint32 nelem) 4) Can we, right away, use this API to replace linear search, say, in SimpleLruReadPage_ReadOnly(), ATExecAttachPartitionIdx(), AfterTriggerSetState()? I'm sure I might be missing other places, but can we replace the possible found areas with the new function? -- Bharath Rupireddy RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/
