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 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 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 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
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
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
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
> 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,
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-
> > 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
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
>
> 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 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
> 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
> 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
> 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.
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
> 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
> 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
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
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
21 matches
Mail list logo
