Re: DBT-5 Stored Procedure Development (2022)

Mark Wong <markwkm@gmail.com>

From: Mark Wong <markwkm@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Mahesh Gouru <mahesh.gouru@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-05-02T14:30:23Z
Lists: pgsql-hackers
On Mon, May 02, 2022 at 07:14:28AM -0700, Mark Wong wrote:
> On Tue, Apr 26, 2022, 10:45 AM Peter Geoghegan <pg@bowt.ie> wrote:
> 
> > On Tue, Apr 26, 2022 at 10:36 AM Mark Wong <markwkm@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