On 2020/11/25 17:07, Fujii Masao wrote:
On 2020/11/25 15:40, Seino Yuki wrote:
2020-11-25 13:13 に Fujii Masao さんは書きました:
On 2020/11/25 12:02, Seino Yuki wrote:
2020-11-17 01:46 に Fujii Masao さんは書きました:
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_in
On 2020/11/25 15:40, Seino Yuki wrote:
2020-11-25 13:13 に Fujii Masao さんは書きました:
On 2020/11/25 12:02, Seino Yuki wrote:
2020-11-17 01:46 に Fujii Masao さんは書きました:
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgs
2020-11-25 13:13 に Fujii Masao さんは書きました:
On 2020/11/25 12:02, Seino Yuki wrote:
2020-11-17 01:46 に Fujii Masao さんは書きました:
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert(pgss_info->
On 2020/11/25 12:02, Seino Yuki wrote:
2020-11-17 01:46 に Fujii Masao さんは書きました:
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert(pgss_info->dealloc == 0);
Why is this assertion c
2020-11-17 01:46 に Fujii Masao さんは書きました:
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert(pgss_info->dealloc == 0);
Why is this assertion check necessary? It seems not necessary.
+
On 2020/11/16 12:22, Seino Yuki wrote:
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert(pgss_info->dealloc == 0);
Why is this assertion check necessary? It seems not necessary.
+ {
+ Assert(found == found_info
Thanks for updating the patch!
+ pgss_info->dealloc = 0;
+ SpinLockInit(&pgss_info->mutex);
+ Assert(pgss_info->dealloc == 0);
Why is this assertion check necessary? It seems not necessary.
+ {
+ Assert(found == found_info);
Having
On 2020/11/09 18:02, Seino Yuki wrote:
2020-11-09 15:39 に Seino Yuki さんは書きました:
However, let me confirm the following.
Is this information really useful?
If there is no valid use case for this, I'd like to drop it.
Thought?
I thought it would be easy for users to see at a glance that if th
2020-11-09 15:39 に Seino Yuki さんは書きました:
However, let me confirm the following.
Is this information really useful?
If there is no valid use case for this, I'd like to drop it.
Thought?
I thought it would be easy for users to see at a glance that if there
is a case I assumed,
if the last modif
However, let me confirm the following.
Is this information really useful?
If there is no valid use case for this, I'd like to drop it.
Thought?
I thought it would be easy for users to see at a glance that if there
is a case I assumed,
if the last modified date and time is old, there is no nee
On 2020/10/28 17:31, seinoyu wrote:
2020-10-22 01:31 に Fujii Masao さんは書きました:
On 2020/10/12 21:18, Yuki Seino wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant:
2020-10-22 01:31 に Fujii Masao さんは書きました:
On 2020/10/12 21:18, Yuki Seino wrote:
The following review has been posted through the commitfest
application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:
On 2020/10/12 21:18, Yuki Seino wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
The patch applies
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
The patch applies cleanly and looks fine to me. It's a small
On 2020-09-24 18:55, legrand legrand wrote:
Not limited to 3, Like an history table.
Will have to think if data is saved at shutdown.
Thanks.
This design might introduce some additional complexity
and things to be considered.
For example, the maximum size of "history table",
how to evict entr
Not limited to 3, Like an history table.
Will have to think if data is saved at shutdown.
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 2020-09-24 14:15, legrand legrand wrote:
Hi,
Both are probably not needed.
I would prefer it accessible in a view live
Event | date | victims
Eviction...
Reset...
Part reset ...
As there are other needs to track reset times.
Let me confirm one thing.
Is the number of records of this view f
Hi,
Both are probably not needed.
I would prefer it accessible in a view live
Event | date | victims
Eviction...
Reset...
Part reset ...
As there are other needs to track reset times.
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On 2020-09-23 16:01, Julien Rouhaud wrote:
Not only providing a view but also logging evictions
along with the number of evicted entries might be a choice.
This idea is from legrand legrand [1].
+1. I'm wondering if logging each evicted entry, with its queryid,
would help to estimate the actua
On 2020-09-19 16:35, legrand legrand wrote:
+1 !
An other way is to log evictions, it provides informations about time
and
amount :
for (i = 0; i < nvictims; i++)
{
hash_search(pgssp_hash, &entries[i]->key, HASH_REMOVE, NULL);
}
pfree(entries);
On Wed, Sep 23, 2020 at 2:48 PM Katsuragi Yuta
wrote:
>
> On 2020-09-18 18:49, Julien Rouhaud wrote:
> > Did you consider also adding the cumulated number of
> > evicted entries? This could be useful to know how to configure
> > pg_stat_statements.max.
>
> Thank you for your comments!
> I overloo
On 2020-09-18 18:49, Julien Rouhaud wrote:
Did you consider also adding the cumulated number of
evicted entries? This could be useful to know how to configure
pg_stat_statements.max.
Thank you for your comments!
I overlooked the cumulated number of evicted entries.
This statistic looks importa
+1 !
An other way is to log evictions, it provides informations about time and
amount :
for (i = 0; i < nvictims; i++)
{
hash_search(pgssp_hash, &entries[i]->key, HASH_REMOVE, NULL);
}
pfree(entries);
/* trace when evicting entries, if app
Hi,
On Fri, Sep 18, 2020 at 10:54 AM Katsuragi Yuta
wrote:
>
> This is a proposal to add some features to pg_stat_statements.
> Attached is the patch of this.
>
> pg_stat_statements uses a hash table to hold statistics,
> and the maximum number of its entries can be configured through
> pg_stat_s
24 matches
Mail list logo
