| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
| Cc: | a(dot)bykov(at)postgrespro(dot)ru, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pgbench-ycsb |
| Date: | 2018-07-21 20:40:59 |
| Message-ID: | alpine.DEB.2.21.1807211628450.22035@lancre |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> Could you provide a link to the specification?
>>
>> I cannot find something simple, and I was kind of hoping to avoid diving
>> into the source code of the java tool on github:-) In particular, I'm
>> looking for a description of the expected underlying schema and its size
>> (scale) parameters.
>
> There are the description files for different workloads, like [1], (with the
> custom amount of records, of course) and the schema [2]. Would this
> information be enough?
>
> [1]: https://github.com/brianfrankcooper/YCSB/blob/master/workloads/workloada
> [2]: https://github.com/brianfrankcooper/YCSB/blob/master/jdbc/src/main/resources/sql/create_table.sql
The second link is a start.
I notice that the submitted patch transactions do not apply to this
schema, which is significantly different from the pgbench TPC-B (like)
benchmark.
The YCSB schema is key -> fields[0-9], all of them TEXT, somehow expected
to be 100 bytes each, and update is expected to update one of these
fields.
This suggest that maybe a -i extension would be in order. Possibly
pgbench -i -s 1 --layout={tpcb,ycsb} (or schema ?)
where "tpcb" would be the default?
I'm sceptical about using a textual primary key as it corresponds more to
NoSQL limitations than to an actual design choice. I'd be okay with INT8
as a pkey.
I find the YSCB tablename "usertable" especially unhelpful. Maybe
"pgbench_ycsb"?
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Darafei Komяpa Praliaskouski | 2018-07-21 20:48:59 | Re: JIT breaks PostGIS |
| Previous Message | Andres Freund | 2018-07-21 20:39:46 | Re: JIT breaks PostGIS |