| From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Clock with Adaptive Replacement |
| Date: | 2018-05-04 11:23:08 |
| Message-ID: | CAB=Je-HC6veTnAOWjV5-xKLykx14RSJshcJ_Ov1fGu5bzNhnfw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>I don't have time to check this out just now, but it seems like an
excellent idea
There are a couple of sad things:
1) DTrace probes seem to be disabled by default. At least, I had to build
PostgreSQL with --enable-dtrace in my macOS.
Does that (the requirement to enable dtrace within PostgreSQL) block from
capturing trace files from real-life applications?
There's an option to use system-level IO trace points (e.g.
https://github.com/omniti-labs/pgtreats/blob/master/tools/pg_file_stress ),
however it would be harder to get DB/relation kind of ids.
2) (database, tablespace, relation) oids cannot be easily mapped from
within a DTrace script. One can workaround that by using a SQL connection
to the database, however it gets a bit complicated if there are multiple DB
instances. What I mean is it is hard to tell which connection URL to use in
order to resolve the oids in question.
Vladimir
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2018-05-04 11:42:36 | Re: unused_oids script is broken with bsd sed |
| Previous Message | Aleksander Alekseev | 2018-05-04 11:18:54 | Re: GSoC 2018: thrift encoding format |