On Mon, May 02, 2022 at 07:14:28AM -0700, Mark Wong wrote: > On Tue, Apr 26, 2022, 10:45 AM Peter Geoghegan <p...@bowt.ie> wrote: > > > On Tue, Apr 26, 2022 at 10:36 AM Mark Wong <mark...@gmail.com> wrote: > > > I'm afraid not. I'm guessing that pulling in egen 1.14 would address > > > that. Maybe it would make sense to put that on the top of todo list if > > > this project is accepted... > > > > Wouldn't it be a prerequisite here? I don't actually have any reason > > to prefer the old function-based code to the new stored procedure > > based code. Really, all I'm looking for is a credible implementation > > of TPC-E that I can use to model some aspects of OLTP performance for > > my own purposes. > > > > TPC-C (which I have plenty of experience with) has only two secondary > > indexes (in typical configurations), and doesn't really stress > > concurrency control at all. Plus there are no low cardinality indexes > > in TPC-C, while TPC-E has quite a few. Chances are high that I'd learn > > something from TPC-E, which has all of these things -- I'm really > > looking for bottlenecks, where Postgres does entirely the wrong thing. > > It's especially interesting to me as somebody that focuses on B-Tree > > indexing.
I think it could be done in either order. While it's not ideal that the kit seems to work most reliably as-is on RHEL/Centos/etc. 6, I think that could provide some confidence in getting familiar with something on a working platform. The updates to the stored functions/procedures would be the same regardless of egen version. If we get the project slot, we can talk further about what to actually tackle first. Regards, Mark