Hi Teodor,
Thanks a lot for a review!
> > step1 In pgstat_report_stat() you remove one by one entries from hash and
> > remove them all. Isn't it better to hash_destroy/hash_create or even let
> > hash
> > lives in separate memory context and just resets it?
Agree, fixed.
> > step1 Again, pgst
Sorry, 1) and 4) is my fault, comment in hsearch.h:
* ... The hash key
* is expected to be at the start of the caller's hash entry data structure.
Ops, forgot that.
Teodor Sigaev wrote:
things in order I'm attaching the previous patch as well.
Patches look good, but I have some notices:
1 st
things in order I'm attaching the previous patch as well.
Patches look good, but I have some notices:
1 step1 Why do you need TabStatHashEntry at all? TabStatHashEntry.t_id is never
used for read, so entry for hash could be just a pointer to PgStat_TableStatus.
2 step1 In pgstat_report_stat(
Also I would like to share some benchmark results.
Before applying any patches (copied from one of previous messages):
```
latency average = 1153.495 ms
latency stddev = 154.366 ms
tps = 6.061104 (including connections establishing)
tps = 6.061211 (excluding connections establishing)
```
After a
Hi Anastasia,
Thanks a lot for a review!
As was mentioned above there is also a bottleneck in find_all_inheritors
procedure. Turned out the problem there is similar and it could be easily
fixed as well. Corresponding patch is attached to this message. To keep
things in order I'm attaching the pre
