From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Mark Wong <markwkm(at)gmail(dot)com> |
Cc: | Mahesh Gouru <mahesh(dot)gouru(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DBT-5 Stored Procedure Development (2022) |
Date: | 2022-04-26 17:44:45 |
Message-ID: | CAH2-WzkAx1eC0txt4SG7_sHveXjp0Fy8fX8Tu3aA8-WO5cqvCg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 26, 2022 at 10:36 AM Mark Wong <markwkm(at)gmail(dot)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.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | David Christensen | 2022-04-26 18:13:04 | Re: [PATCH] Teach pg_waldump to extract FPIs from the WAL |
Previous Message | Mark Wong | 2022-04-26 17:36:17 | Re: DBT-5 Stored Procedure Development (2022) |