On Fri, Feb 18, 2022 at 10:48 PM Simon Riggs
wrote:
>
> On Thu, 17 Feb 2022 at 17:55, Sadhuprasad Patro wrote:
> >
> > > On Sat, Feb 12, 2022 at 2:35 AM Robert Haas wrote:
> > >>
> > >>
> > >> Imagine that I am using the "foo"
On Tue, Mar 22, 2022 at 7:24 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-24 12:26:08 +0530, Sadhuprasad Patro wrote:
> > I have added a dummy test module for table AM and did the document
> > change in the latest patch attached...
>
> The test module doesn
On Tue, Oct 26, 2021 at 6:55 PM Shruthi Gowda wrote:
>
>
> I have revised the patch w.r.t the way 'create_storage' is interpreted
> in heap_create() along with some minor changes to preserve the DBOID
> patch.
>
Hi Shruthi,
I am reviewing the attached patches and providing a few comments here
be
Hi,
Currently all the storage options for a table are very much specific
to the heap but a different AM might need some user defined AM
specific parameters to help tune the AM. So here is a patch which
provides an AM level routine so that instead of getting parameters
validated using “heap_relopti
Hi All,
Publisher 'DateStyle' is set as "SQL, MDY", whereas in Subscriber as
"SQL, DMY", the logical replication is not working...
>From Publisher:
postgres=# INSERT INTO calendar VALUES ('07-18-1036', '1'), ('05-15-1135', '1');
INSERT 0 2
Getting below error in the subscriber log file,
2021-10-
> Add a test case in subscription/t/100_bugs.pl. Please consider the v2 patch
> for review.
>
Reviewed and tested the patch, it works fine... There are some
trailing spaces present in the newly added code lines, which needs to
be corrected...
Doing some further testing with different datestyles,
On Fri, Oct 22, 2021 at 8:07 AM Japin Li wrote:
>
>
> On Fri, 22 Oct 2021 at 08:26, Masahiko Sawada wrote:
> > On Thu, Oct 21, 2021 at 11:18 PM Japin Li wrote:
> >>
> >> How it breaks?
> >
> > I don't know the real case but for example, if an application gets
> > changes via pg_recvlogical with
On Mon, Jan 17, 2022 at 4:47 PM Jelte Fennema wrote:
>
> Big +1, this is a great addition!
>
> I think it would be very useful if there were some tests for this new
> feature. Something similar to the tests for storage parameters for
> index AMs in src/test/modules/dummy_index_am.
>
Sure, I will r
> On Sat, Feb 12, 2022 at 2:35 AM Robert Haas wrote:
>>
>>
>> Imagine that I am using the "foo" tableam with "compression=lots" and
>> I want to switch to the "bar" AM which does not support that option.
>> If I remove the "compression=lots" option using a separate command,
>> the "foo" table AM m
On Fri, Aug 13, 2021 at 11:40 AM Dilip Kumar wrote:
>
> On Fri, Aug 13, 2021 at 9:31 AM Amit Kapila wrote:
> >
> > On Thu, Aug 12, 2021 at 8:30 PM Robert Haas wrote:
> > >
> > > On Thu, Aug 12, 2021 at 12:22 AM Amit Kapila
> > > wrote:
> > > > The design of the patch has changed since the init
>
> That's a significant difference. Have you checked via perf or some
> other way what causes this difference? I have seen that sometimes
> single client performance with pgbench is not stable, so can you
> please once check with 4 clients or so and possibly with a larger
> dataset as well.
I hav
On Wed, Sep 1, 2021 at 5:31 PM Fujii Masao wrote:
>
>
>
> On 2021/08/24 13:07, Mahendra Singh Thalor wrote:
> > Thanks Sadhu for the updated patch.
> >
> > Patch looks good to me and I don't have any more comments.
> >
> > I marked this patch as 'ready for committer'.
> > https://commitfest.postgr
> > One more thing to consider is that it seems that the planner requires
> > a condition for the first column of an index before considering an
> > indexscan plan. See Tom's email [1] in this regard. I think it would
> > be better to see what kind of work is involved there if you want to
> > explo
Hi,
The call to “pg_stat_reset“ does reset all the statistics data for
tables belonging to the current database but does not take care of
shared tables e.g pg_attribute. Similarly to reset the statistics at
table level, the call to “pg_stat_reset_single_table_counters“ does
not take care of shared
Hi,
> > 3)
> > pgstat_recv_resetsinglecounter(PgStat_MsgResetsinglecounter *msg, int len)
> > {
> > PgStat_StatDBEntry *dbentry;
> > +boolfound;
> >
> > dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
> >
> > @@ -5168,13 +5192,41 @@
> > pgstat_recv_resetsinglecount
> 3) I am attaching a .sql file. We can add similar types of test cases for
> shared tables.
> Ex: first reset stats for all shared tables using pg_stat_reset and then
> check stats for all shared tables(all should be zero)
Adding a new test case for this looks difficult as results are not
consi
> As of now, we are adding handling inside pg_stat_reset for shared
> tables but I think we can add a new function with the name of
> pg_stat_reset_shared_tables to reset stats for all the shared tables.
> New function will give more clarity to the users also. We already have
> a pg_stat_reset_shar
On Wed, Aug 11, 2021 at 10:30 AM Mahendra Singh Thalor
wrote:
>
> On Wed, 11 Aug 2021 at 09:17, Dilip Kumar wrote:
> >
> > On Tue, Aug 10, 2021 at 10:49 PM Mahendra Singh Thalor
> > wrote:
> >
> > > I checked this and found that we already have one process "stats
> > > collector" and in v02 patc
> If we do support resetting the stats for shared tables in
> 'pg_stat_reset', which is for DB level,
> then the stats of shared tables will be reseted in other instances as
> well, which seems to be not correct.
> So we need to provide some way to reset the stats for shared tables to
> customers.
> 3)
> - dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
> + if (!IsSharedRelation(msg->m_objectid))
> + dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
> + else
> + dbentry = pgstat_get_db_entry(InvalidOid, false);
>
> We should add s
> On 2021/08/20 11:07, Mahendra Singh Thalor wrote:
> > 1)
> > Resets statistics for a single table or index in the current
> > database
> > -to zero.
> > +to zero. The input can be a shared table also
> >
> > I think, above comment should be modified. Maybe, we can modif
21 matches
Mail list logo
