> > I am not sure if this benchmark is enough to build confidence in this
> > approach.
> > Workloads with nested queries and tack. 'all' are now paying an even heavier
> > cost.
>
> I would love to see and test sql that will reveal the bigger overhead.
> Do you have something specific on your mind? I'd love to share
> results, we can use them later considering further updates to pgss.
Here is something I was experimenting with today. I ran 2
benchmarks; one on HEAD and one with GetCurrentTimestamp()
added when we are accumulating stats.
"""
/* Increment the counts, except when jstate is not NULL */
if (!jstate)
{
Assert(kind == PGSS_PLAN || kind == PGSS_EXEC);
GetCurrentTimestamp();
"""
The benchmak script is a series of "SELECT;"
# select_tx.sql
"""
begin;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
select;
end;
"""
The benchmark was on my Ubuntu on EC2 c5a.12xlarge,
with default pg_stat_statements settings ( no plan tracking
and top tracking only ).
pgbench command:
```
pgbench -c48 -j16 -P1 -f select_tx.sql -T120
```
Results for 3 runs
## HEAD
tps = 29351.794589 (without initial connection time)
tps = 29470.287111 (without initial connection time)
tps = 29902.245458 (without initial connection time)
## with GetCurrentTimestamp()
tps = 28569.471891 (without initial connection time)
tps = 28013.051778 (without initial connection time)
tps = 28518.468843 (without initial connection time)
I see around 4-5% performance degradation.
--
Sami Imseih
Amazon Web Services (AWS)
