結果解讀

良好的結果會顯示大部分（>90%）的單個計時呼叫耗時不到一微秒。每次迴圈的平均開銷會更低，低於 100 納秒。這個來自使用 TSC 時鐘源的 Intel i7-860 系統的示例顯示了出色的效能。

Testing timing overhead for 3 seconds.
Per loop time including overhead: 35.96 ns
Histogram of timing durations:
  < us   % of total      count
     1     96.40465   80435604
     2      3.59518    2999652
     4      0.00015        126
     8      0.00002         13
    16      0.00000          2

請注意，每次迴圈時間和直方圖使用的是不同的單位。迴圈的精度可能達到幾納秒（ns），而單個計時呼叫只能精確到一微秒（us）。

測量執行器計時開銷

當查詢執行器使用 EXPLAIN ANALYZE 執行語句時，除了顯示摘要外，還會對單個操作進行計時。可以透過 psql 程式計數行來檢查系統的開銷。

CREATE TABLE t AS SELECT * FROM generate_series(1,100000);
\timing
SELECT COUNT(*) FROM t;
EXPLAIN ANALYZE SELECT COUNT(*) FROM t;

在 i7-860 系統上測得，count 查詢執行時間為 9.8 ms，而 EXPLAIN ANALYZE 版本耗時 16.6 ms，每個都處理了略多於 100,000 行。這 6.8 ms 的差值意味著每行的計時開銷為 68 ns，大約是 pg_test_timing 估計值的兩倍。即使是如此小的開銷，也使得完全計時的 count 語句的執行時間增加了近 70%。對於更復雜的查詢，計時開銷的影響會較小。

更改時間源

在一些較新的 Linux 系統上，可以隨時更改用於收集計時資料的時鐘源。第二個示例顯示了在與上述快速結果相同的系統上，切換到較慢的 acpi_pm 時間源可能導致的效能下降。

# cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
# pg_test_timing
Per loop time including overhead: 722.92 ns
Histogram of timing durations:
  < us   % of total      count
     1     27.84870    1155682
     2     72.05956    2990371
     4      0.07810       3241
     8      0.01357        563
    16      0.00007          3

在此配置下，上述示例的 EXPLAIN ANALYZE 耗時 115.9 ms。這相當於 1061 ns 的計時開銷，再次是此工具直接測量的幾倍。如此大的計時開銷意味著實際查詢本身只佔用了很小一部分時間，大部分時間都被開銷消耗掉了。在此配置下，任何涉及大量計時的 EXPLAIN ANALYZE 總計時間都會因計時開銷而顯著膨脹。

FreeBSD 也允許動態更改時間源，並且會在啟動時記錄有關選定計時器資訊。

# dmesg | grep "Timecounter"
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "TSC" frequency 2531787134 Hz quality 800
# sysctl kern.timecounter.hardware=TSC
kern.timecounter.hardware: ACPI-fast -> TSC

其他系統可能只允許在啟動時設定時間源。在較舊的 Linux 系統上，“clock”核心設定是進行此類更改的唯一方法。甚至在一些較新的系統上，您看到的唯一時鐘源選項是“jiffies”。Jiffies 是較舊的 Linux 軟體時鐘實現，當它由足夠快的硬體支援時，可以提供良好的解析度，如本例所示。

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
$ dmesg | grep time.c
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 2400.153 MHz processor.
$ pg_test_timing
Testing timing overhead for 3 seconds.
Per timing duration including loop overhead: 97.75 ns
Histogram of timing durations:
  < us   % of total      count
     1     90.23734   27694571
     2      9.75277    2993204
     4      0.00981       3010
     8      0.00007         22
    16      0.00000          1
    32      0.00000          1

時鐘硬體和計時精度

在計算機上收集準確的計時資訊通常使用不同精度的硬體時鐘。透過某些硬體，作業系統可以將系統時鐘時間幾乎直接傳遞給程式。系統時鐘也可以派生自一個晶片，該晶片僅提供計時中斷，即以已知時間間隔進行的週期性滴答。無論哪種情況，作業系統核心都提供一個隱藏這些細節的時鐘源。但是該時鐘源的精度以及它返回結果的速度會因底層硬體而異。

不準確的時間記錄可能導致系統不穩定。請非常仔細地測試對時鐘源的任何更改。作業系統預設設定有時會優先考慮可靠性而不是最佳精度。如果您使用的是虛擬機器，請查詢與之相容的推薦時間源。虛擬硬體在模擬計時器時會面臨額外的困難，並且通常會有供應商建議的每個作業系統設定。

時間戳計數器（TSC）時鐘源是當前一代 CPU 上最精確的可用時鐘源。當作業系統支援並且 TSC 時鐘可靠時，它是跟蹤系統時間的首選方式。TSC 有幾種方式可能無法提供準確的計時源，使其變得不可靠。舊系統可能有一個 TSC 時鐘，該時鐘會根據 CPU 溫度而變化，使其無法用於計時。在某些較舊的多核 CPU 上嘗試使用 TSC 可能會導致報告的時間在多個核心之間不一致。這可能導致時間倒退，這是本程式檢查的一個問題。即使是最新系統，在非常激進的省電配置下也可能無法提供準確的 TSC 計時。

較新的作業系統可能會檢查已知的 TSC 問題，並在看到這些問題時切換到較慢、更穩定的時鐘源。如果您的系統支援 TSC 時間但不預設使用它，這可能是有充分理由停用了它。並且一些作業系統可能無法正確檢測到所有可能的問題，或者即使在已知不準確的情況下也允許使用 TSC。

高精度事件計時器（HPET）是 TSC 不準確時系統中首選的計時器。計時器晶片本身可程式設計，允許高達 100 納秒的解析度，但您的系統時鐘可能無法達到如此高的精度。

高階配置和電源介面（ACPI）提供了一個電源管理（PM）計時器，Linux 將其稱為 acpi_pm。從 acpi_pm 派生的時鐘最好能提供 300 納秒的解析度。

在較舊的 PC 硬體上使用的計時器包括 8254 可程式設計間隔計時器（PIT）、即時時鐘（RTC）、高階可程式設計中斷控制器（APIC）計時器和 Cyclone 計時器。這些計時器的目標是毫秒級解析度。