Re: Assert in pg_stat_statements - Mailing list pgsql-hackers

From Satoshi Nagayasu
Subject Re: Assert in pg_stat_statements
Date
Msg-id CAA8soze0Syf-1zPB9Y-txzFwH7ZO32ZaaEQ3y1p_bYcWKhyucw@mail.gmail.com
Whole thread Raw
In response to Re: Assert in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2015-08-10 2:23 GMT+09:00 Tom Lane <tgl@sss.pgh.pa.us>:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I'm not too excited about supporting the use case where there are two
>> people using queryId but it just so happens that they always set
>> exactly the same value.  That seems like a weird setup.  Wouldn't that
>> mean both modules were applying the same jumble algorithm, and
>> therefore you're doing the work of computing the jumble twice per
>> query?
>
> Not only that, but you'd need to keep the two modules in sync, which
> would be one of the greatest recipes for bugs we've thought of yet.
>
> If there's actually a use case for that sort of thing, I would vote
> for moving the jumble-calculation code into core and making both of
> the interested extensions do
>
>         /* Calculate query hash if it's not been done yet */
>         if (query->queryId == 0)
>                 calculate_query_hash(query);

I vote for this too.

Jumble-calculation is the smartest way to identify query groups,
so several modules can take advantages of it if in the core.

Regards,
-- 
Satoshi Nagayasu <snaga@uptime.jp>



pgsql-hackers by date:

Previous
From: Satoshi Nagayasu
Date:
Subject: Re: Assert in pg_stat_statements
Next
From: David Fetter
Date:
Subject: Re: [patch] A \pivot command for psql