Re: [HACKERS] Clock with Adaptive Replacement
От | Vladimir Sitnikov |
---|---|
Тема | Re: [HACKERS] Clock with Adaptive Replacement |
Дата | |
Msg-id | CAB=Je-HC6veTnAOWjV5-xKLykx14RSJshcJ_Ov1fGu5bzNhnfw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Clock with Adaptive Replacement (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
>I don't have time to check this out just now, but it seems like an
excellent idea
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
В списке pgsql-hackers по дате отправления: