Re: DBT-5 Stored Procedure Development (2022)
От | Peter Geoghegan |
---|---|
Тема | Re: DBT-5 Stored Procedure Development (2022) |
Дата | |
Msg-id | CAH2-WzkAx1eC0txt4SG7_sHveXjp0Fy8fX8Tu3aA8-WO5cqvCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: DBT-5 Stored Procedure Development (2022) (Mark Wong <markwkm@gmail.com>) |
Список | pgsql-hackers |
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. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: