|From:||"Gunnar \"Nick\" Bluth" <gunnar(dot)bluth(at)pro-open(dot)de>|
|Subject:||Re: [PATCH] pg_stat_toast v0.4|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Am 21.12.21 um 13:51 schrieb kuroda(dot)hayato(at)fujitsu(dot)com:
> Dear Gunnar,
thanks for the feedback!
>> * gathering timing information
> Here is a minor comment:
> I'm not sure when we should start to measure time.
> If you want to record time spent for compressing, toast_compress_datum() should be
> sandwiched by INSTR_TIME_SET_CURRENT() and caclurate the time duration.
> Currently time_spent is calcurated in the pgstat_report_toast_activity(),
> but this have a systematic error.
> If you want to record time spent for inserting/updating, however,
> I think we should start measuring at the upper layer, maybe heap_toast_insert_or_update().
Yes, both toast_compress_datum() and toast_save_datum() are sandwiched
the way you mentioned, as that's exactly what we want to measure (time
spent doing compression and/or externalizing data).
Implementation-wise, I (again) took "track_functions" as a template
there, assuming that jumping into pgstat_report_toast_activity() and
only then checking if "track_toast = on" isn't too costly (we call
pgstat_init_function_usage() and pgstat_end_function_usage() a _lot_).
I did miss though that
should be called right after entering pgstat_report_toast_activity(), as
that might need additional clock ticks for setting up the hash etc.
That's fixed now.
What I can't assess is the cost of the unconditional call to
INSTR_TIME_SET_CURRENT(start_time) in both toast_tuple_try_compression()
Would it be wise (cheaper) to add a check like
before querying the system clock?
>> Any hints on how to write meaningful tests would be much appreciated!
>> I.e., will a test
> I searched hints from PG sources, and I thought that modules/ subdirectory can be used.
> Following is the example:
> I attached a patch to create a new test. Could you rewrite the sql and the output file?
Thanks for the kickstart ;-)
Some tests (as meaningful as they may get, I'm afraid) are now in
"make check-world" executes them successfully, although only after I
introduced a "SELECT pg_sleep(1);" to them.
Gunnar "Nick" Bluth
Mobil +49 172 8853339
"Ceterum censeo SystemD esse delendam" - Cato
|Next Message||Stanislav Bashkyrtsev||2022-01-03 15:54:49||PostgreSQL stops when adding a breakpoint in CLion|
|Previous Message||gkokolatos||2022-01-03 15:35:57||Re: Refactoring of compression options in pg_basebackup|