解讀結果

良好的結果會顯示大多數（>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 系統在 9.8 毫秒內執行計數查詢，而 EXPLAIN ANALYZE 版本需要 16.6 毫秒，每個版本處理超過 100,000 行。 6.8 毫秒的差異表示每行的時間額外負荷為 68 奈秒，約為 pg_test_timing 估計值的兩倍。即使是相對較小的額外負荷，也使得完全計時的計數語句花費的時間增加了近 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 毫秒。 這是 1061 奈秒的時間額外負荷，再次是該工具直接測量值的幾倍。 這麼多的時間額外負荷表示實際查詢本身僅佔所佔時間的一小部分，大部分都被額外負荷消耗了。 在此配置中，任何涉及許多計時操作的 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 無法提供準確的計時來源有多種方式，使其不可靠。 較舊的系統可能具有基於 CPU 溫度而變化的 TSC 時鐘，使其無法用於計時。 嘗試在某些較舊的多核心 CPU 上使用 TSC 會導致報告的時間在多個核心之間不一致。 這可能會導致時間倒退，此程式會檢查此問題。 即使是最新的系統也可能無法透過非常積極的節省電源配置來提供準確的 TSC 計時。

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

高效能事件計時器 (HPET) 是系統上首選的計時器，前提是該系統可用 HPET 且 TSC 不準確。計時器晶片本身是可編程的，可達到高達 100 奈秒的解析度，但您可能無法在系統時鐘中看到那麼高的準確度。

進階組態與電源介面 (ACPI) 提供電源管理 (PM) 計時器，Linux 將其稱為 acpi_pm。從 acpi_pm 衍生的時鐘最多可提供 300 奈秒的解析度。

較舊的 PC 硬體上使用的計時器包括 8254 可程式化間隔計時器 (PIT)、即時時鐘 (RTC)、進階可程式化中斷控制器 (APIC) 計時器和 Cyclone 計時器。 這些計時器的目標是達到毫秒解析度。