atch.
Thanks Ahustosh, yeah I have observed the same, earlier we were
directly copying the whole directory so this was not an issue, now if
some tables of the database are already in the destination tablespace
then we should skip them while copying. I will review your patch and
merge into the main patch.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Dec 7, 2021 at 10:29 AM Nikolay Samokhvalov
wrote:
>
> On Mon, Dec 6, 2021 at 8:16 PM Dilip Kumar wrote:
>>
>> If the subtransaction cache is overflowed in some of the transactions
>> then it will affect all the concurrent queries as they need to access
le who want to could use it like:
> SELECT * FROM pg_stat_activity psa, pg_backend_get_subxact_status(pid) sub;
Yeah, this is a valid point, I will change this accordingly.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
unt of resource
which is true for any other operation e.g. ALTER TABLE SET TABLESPACE
so now it is in more sync with the rest of the system, but without the
patch, it was a special purpose forced checkpoint only for the
createdb.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
-t5BkwdHm1bV8ez64guWZJB_Jjhb7arsQsftxEwpYwObg%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 622e1012667c3cfa0c71f27590e2a49833970e22 Mon Sep 17 00:00:00 2001
From: Dilip Kumar
Date: Sun, 5 Dec 2021 17:56:16 +0530
Subject: [PATCH v1] Add subtransaction count and overflow status
nvert the UPDATE to
DELETE OTOH if only new is matching the filter then convert the UPDATE
to INSERT. Do you think that even we merge 0001 and 0003 then also
there is an open issue regarding which row to select for the filter?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
use_wal = XLogIsNeeded() &&
> + (relpersistence == RELPERSISTENCE_PERMANENT || copying_initfork);
>
Since we are creating new relfilenode this is fine, refer "Skipping
WAL for New RelFileNode" in src/backend/access/transam/README
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
SE in a less cheesy way,
* we can avoid this.
*/
RequestCheckpoint(CHECKPOINT_IMMEDIATE | CHECKPOINT_FORCE | CHECKPOINT_WAIT);
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Dec 3, 2021 at 5:00 PM Simon Riggs wrote:
>
> On Fri, 3 Dec 2021 at 01:27, Dilip Kumar wrote:
>
> > > On review, I think it is also possible that we update subtrans ONLY if
> > > someone uses >PGPROC_MAX_CACHED_SUBXIDS.
> > > This would make subtra
SUBXIDS?
But the TransactionIdDidCommit(), might need to fetch the parent if
the transaction status is TRANSACTION_STATUS_SUB_COMMITTED, so how
would we handle that?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Dec 1, 2021 at 6:04 PM Dilip Kumar wrote:
> Thanks a lot for testing this. From the error, it seems like some of
> the old buffer w.r.t. the previous tablespace is not dropped after the
> movedb. Actually, we are calling DropDatabaseBuffers() after copying
> to a ne
On Wed, Dec 1, 2021 at 12:07 PM Greg Nancarrow wrote:
>
> On Thu, Nov 25, 2021 at 10:17 PM Dilip Kumar wrote:
> >
> > Thanks for the review and many valuable comments, I have fixed all of
> > them except this comment (/* If we got a cancel signal during the copy
> >
s or we are going to apply only the insert
> > filters?
> >
>
> AFAIK, currently, initial table sync doesn't respect publication
> actions so it should combine all the filters. What do you think?
Yeah, I have the same opinion.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
n this particular relation so this recache
entry should not be invalidated at least in the example you have
given.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
utput_row_filter). It is
> okay to combine them at a later stage during execution when we can't
> do it at the time of forming cache entry.
What about the initial table sync? during that, we are going to
combine all the filters or we are going to apply only the insert
filters?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
hem they are initialized,
and most of them are allocated while building the relation descriptor
see RelationBuildDesc().
So if you keep some random pointer in RelationData without ensuring
that is getting reinitialized while building the relation cache then I
think that's not the correct way to do it.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
e WAL is locally
available and we don't really need more WAL but that is controlled by
a GUC.
[1]
https://www.postgresql.org/message-id/CAKYtNApe05WmeRo92gTePEmhOM4myMpCK_%2BceSJtC7-AWLw1qw%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
r as well but that makes it tricky to explain. I feel we can
> change it later as well if there is a valid use case for this. What do
> you think?
Yeah, that makes sense.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
as per that this will become the INSERT
operation because the old row was not passing the filter. So now we
will insert a new row in the subscriber-side with value (2,3). Looks
a bit odd to me that the value b=3 would have been rejected with the
direct insert but it is allowed due to indirect insert done by update.
Is this behavior looks odd only to me?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Nov 29, 2021 at 12:19 PM Bharath Rupireddy
wrote:
>
> On Mon, Nov 29, 2021 at 11:14 AM Dilip Kumar wrote:
> >
> > On Mon, Nov 29, 2021 at 9:40 AM Bharath Rupireddy
> > wrote:
> > >
> > > On Mon, Nov 29, 2021 at 1:48 AM SATYANARAYANA NARLAPURAM
et overflowed?
This is a 64-bit variable so I am not sure do we really need to worry
about overflow? I mean if we are storing microseconds then also this
will be able to last for ~300,000 years no?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
at the
> latest information exists say when the subscriber is down/crashed
> before it picks up the latest slot information?
Yeah that is a good question that how frequently the subscriber should
fetch the slot information, I think that should be configurable
values. And the time delay is more, the chances of losing the latest
slot is more.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
dle_in_xact_time.
>
> Got it.
> Updated
Okay, thanks, I will look into it one more time early next week and if
I see no issues then I will move it to RFC.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Nov 25, 2021 at 1:07 PM Greg Nancarrow wrote:
>
> On Tue, Oct 5, 2021 at 7:07 PM Dilip Kumar wrote:
> >
> > Patch details:
> > 0001 to 0006 implements an approach1
> > 0007 removes the code of pg_class scanning and adds the directory scan.
> >
>
>
-format will conflict, --foo is also
not allowed because it is not a valid prefix string of any valid
option string.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
m.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
nstead of just dead, why not deadtid or deaditem?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
eems cleaner to me 2) with 0007 if we directly scan directory we
don't know the relation oid, so before acquiring the buffer lock there
is no way to acquire the relation lock.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
a commit, that'd be an
> actual durability issue.
I think at this thread[1], which claimed to get this issue even after
commit, I haven't tried it myself though.
[1]
https://www.postgresql.org/message-id/flat/ea6485e3-98d0-24a7-094c-87f9d5f9b18f%40amazon.com#4cfe7217c829419b769339465e8c2915
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
MemoryContextSwitchTo(CacheMemoryContext);
tupdesc = CreateTupleDescCopy(tupdesc);
entry->scantuple = MakeSingleTupleTableSlot(tupdesc, );
Why do we need to copy the tupledesc? do we think that we need to have
this slot even if we close the relation, if so can you add the
comments
On Mon, Nov 22, 2021 at 4:25 PM Bharath Rupireddy
wrote:
>
> On Sun, Nov 14, 2021 at 11:45 AM Dilip Kumar wrote:
> >
> > On Wed, Oct 27, 2021 at 1:01 AM Mahendra Singh Thalor
> > wrote:
> >
> > I was going through and patch and trying to understand
On Mon, Nov 15, 2021 at 2:44 PM Dilip Kumar wrote:
>
> On Fri, Nov 12, 2021 at 3:49 PM Ajin Cherian wrote:
> >
> > Attaching version 39-
I have reviewed, 0001* and I have a few comments on it
---
>If you choose to do the initial table synchronization, only data that satis
On Mon, Nov 15, 2021 at 4:46 PM Rafia Sabih wrote:
>
> On Mon, 15 Nov 2021 at 10:24, Dilip Kumar wrote:
> >
> > On Wed, Nov 10, 2021 at 1:47 PM Rafia Sabih
> > wrote:
> > >
> > > > It seems that in beentry->st_idle_time, you want to compute the
&
On Mon, 15 Nov 2021 at 3:07 PM, Amit Kapila wrote:
> On Mon, Nov 15, 2021 at 2:44 PM Dilip Kumar wrote:
> >
> > On Fri, Nov 12, 2021 at 3:49 PM Ajin Cherian wrote:
> > >
> >
> > This function definition header is too long to fit in one line, so
>
amed to "pgStatIdleTime" and
pgStatTransactionIdleInTxnTime should be renamed to
"pgStatTransactionIdleTime"
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
n, HeapTuple
oldtuple, HeapTuple newtuple, RelationSyncEntry *entry,
ReorderBufferChangeType *action)
+{
This function definition header is too long to fit in one line, so
better to break it. I think running will be a good idea.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Nov 15, 2021 at 11:53 AM Bharath Rupireddy
wrote:
>
> On Mon, Nov 15, 2021 at 11:37 AM Dilip Kumar wrote:
> >
> > On Mon, Nov 15, 2021 at 10:34 AM vignesh C wrote:
> >
> > >
> > > Thanks for the comments, the attached v12 patch has the c
is not supported by this installation
+ pg_print_backtrace
+
+ f
Should we give some hints on how to enable that?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
then we
might fetch the WAL using both walreceiver as well as from archive
right? because we are not changing the currentsource. Is this
intentional or do we want to change the currentsource as well?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Nov 9, 2021 at 8:28 PM Rafia Sabih wrote:
>
> On Tue, 2 Nov 2021 at 09:00, Dilip Kumar wrote:
> >
> > About the patch, IIUC earlier all the idle time was accumulated in the
> > "pgStatTransactionIdleTime" counter, now with your patch you have
>
why are we trying to use this as rvalue here? This
is clearly an issue.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
her returns -1 or returns XLOG_BLCKSZ. So logically this function
should just be returning boolean, true if it is able to read the first
page, or false otherwise.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Nov 9, 2021 at 11:57 AM Amit Kapila wrote:
>
> On Tue, Nov 9, 2021 at 11:37 AM Dilip Kumar wrote:
> > 1.
> > I don't like the fact that this view is very specific for showing the
> > errors but the name of the view is very generic. So are we keeping
> >
t contain this column.
6.
+
+Resets statistics of a single subscription worker statistics.
/Resets statistics of a single subscription worker statistics/Resets
statistics of a single subscription worker
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Oct 19, 2021 at 2:25 PM Dilip Kumar wrote:
>
> On Tue, Oct 12, 2021 at 11:30 AM Dilip Kumar wrote:
> >
> > On Tue, Oct 12, 2021 at 10:35 AM Kyotaro Horiguchi
> > wrote:
> > >
> > > At Tue, 12 Oct 2021 13:59:59 +0900 (JST), Kyotaro Horig
BORTED should
be accumulated in the "pgStatTransactionIdleInTxnTime" counter or
there should be a separate counter for that. But after your patch we
can not accumulate this in the "pgStatTransactionIdleTime" counter.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
say "Autovacuum". Attached
> patch does that. Please review it.
+1, the error message and other improvements look good.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Oct 26, 2021 at 9:19 AM Amit Kapila wrote:
>
> On Mon, Oct 25, 2021 at 4:21 PM Amit Kapila wrote:
> >
> > On Thu, Oct 21, 2021 at 11:20 AM Dilip Kumar wrote:
> > >
> > > On Thu, Oct 21, 2021 at 9:11 AM Amit Kapila
> > > wrote:
> > &g
On Tue, Oct 26, 2021 at 2:31 PM Amit Kapila wrote:
>
> On Fri, Oct 15, 2021 at 1:48 AM Robert Haas wrote:
> >
> > On Tue, Oct 12, 2021 at 10:14 AM Dilip Kumar wrote:
> > > Thanks, yeah now it looks in line with other results.
> >
> > Since it seems there
On Thu, Oct 21, 2021 at 11:16 AM Masahiko Sawada wrote:
>
> On Wed, Oct 20, 2021 at 8:12 PM Japin Li wrote:
> >
> >
> > On Mon, 18 Oct 2021 at 17:27, Dilip Kumar wrote:
> > > On Mon, Oct 18, 2021 at 1:41 PM Japin Li wrote:
> > >
> > >> I
On Thu, Oct 21, 2021 at 9:11 AM Amit Kapila wrote:
>
> On Wed, Oct 20, 2021 at 8:49 PM Dilip Kumar wrote:
> >
> > On Wed, Oct 20, 2021 at 7:09 PM Alvaro Herrera
> > wrote:
> > >
> > > Does MarkTopTransactionIdLogged() have to be inside XLogInsertRecord
On Wed, Oct 20, 2021 at 9:46 PM Alvaro Herrera wrote:
>
> On 2021-Oct-20, Dilip Kumar wrote:
>
> > On Wed, Oct 20, 2021 at 7:09 PM Alvaro Herrera
> > wrote:
>
> > > In IsTopTransactionIdLogPending(), I suggest to reorder the tests so
> > > that the fast
ecord's
> critical section?
I think this function is doing somewhat similar things to what we are
doing in MarkCurrentTransactionIdLoggedIfAny() so put at the same
place. But I don't see any reason for this to be in the critical
section.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Oct 20, 2021 at 4:17 PM Amit Kapila wrote:
>
> On Wed, Oct 20, 2021 at 10:25 AM Dilip Kumar wrote:
> >
> > I have one comment here, basically, you have changed the function name
> > to "IsTopTransactionIdLogged", but it still behaves like
>
On Wed, Oct 20, 2021 at 5:06 PM Amit Kapila wrote:
>
> On Tue, Oct 12, 2021 at 6:21 PM Dilip Kumar wrote:
> >
> > While working on the issue [1], I realize that if a subtransaction
> > hasn't done any catalog change then we don't add this in the commit
> > xid list
ote that the corresponding table
> in the subscriber may well be a non-partitioned table (or the
> partitions arranged differently) so the data does need to be
> replicated again.
I don't think this behavior is consistent, I mean for the initial sync
we will replicate the duplicate data, whereas for later streaming we
will only replicate it once. From the user POW, this behavior doesn't
look correct.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
be changed accordingly. Other changes look fine.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Oct 12, 2021 at 11:30 AM Dilip Kumar wrote:
>
> On Tue, Oct 12, 2021 at 10:35 AM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 12 Oct 2021 13:59:59 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> > > So I came up with the attached version.
> >
ched the fix.
Thanks!
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
e also we consider this table only once and there will be
no duplicate data.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
e.
> Please try v3 patch and let me know if they work as unexpected.
> Thanks in advance.
I think the idea of setting the standard DateStyle and the
IntervalStyle on the walsender process looks fine to me. As this will
avoid extra network round trips as Tom mentioned.
--
Regards,
Dilip
earExportedSnapshot because that is anyway being called
from the AbortTransaction.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 062a84dcd821fa5e41998c8714f8ec16befcf983 Mon Sep 17 00:00:00 2001
From: Dilip Kumar
Date: Mon, 11 Oct 2021 20:38:58 +0530
Subject: [PATCH v2]
ou need a
> different "datestyle" setting.
>
> Is this an expected behavior?
Looks like a problem to me, I think for fixing this, on logical
replication connection always set subscriber's DateStlyle, with that
the walsender will always send the data in the same DateSt
On Thu, Oct 14, 2021 at 12:24 PM Michael Paquier wrote:
>
> On Wed, Oct 13, 2021 at 10:53:24AM +0530, Dilip Kumar wrote:
> > Actually, it is not required because 1) Snapshot export can not be
> > allowed within a transaction block, basically, it starts its own
> > tran
if
someone tries to set with the column name then it should throw an
error.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Oct 13, 2021 at 10:17 AM Michael Paquier wrote:
>
> On Mon, Oct 11, 2021 at 08:46:32PM +0530, Dilip Kumar wrote:
> > As reported at [1], if the transaction is aborted during export
> > snapshot then ExportInProgress and SavedResourceOwnerDuringExport are
>
On Tue, Oct 12, 2021 at 6:41 PM Tomas Vondra
wrote:
>
> On 9/28/21 14:00, Dilip Kumar wrote:
> >
> > I think that would be great, can we just test this specific target
> > where we are seeing a huge dip with the patch, e.g.
> > with 1000 rows, 10 columns and
s_timetravel = true;
needs_snapshot = true;
[3]
[1]
https://www.postgresql.org/message-id/CAFiTN-tqopqpfS6HHug2nnOGieJJ_nm-Nvy0WBZ%3DZpo-LqtSJA%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
ve in mind, I will do a
detailed review in a day or two. Thanks for working on this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
tch clears this state if
the transaction is aborted.
[1]
https://www.postgresql.org/message-id/CAFiTN-tqopqpfS6HHug2nnOGieJJ_nm-Nvy0WBZ=zpo-lqt...@mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 673bea5121f0a6acadb1304e4a2b1027f5914e72 Mon Sep 17 00:00:00
e
for expression evaluation machinery and later the expression
evaluation we do the deform again.
So why don't you use the deformed tuple as it is to store as a virtual tuple?
Infact, if newtup_changed is true then you are forming back the tuple
just to get it deformed again
in the expression
On Mon, Oct 11, 2021 at 4:29 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 11 Oct 2021 11:49:41 +0530, Dilip Kumar wrote
> in
> > While creating an "export snapshot" I don't see any protection why the
> > number of xids in the snapshot can not cross
on abort, for this,
a simple fix is we can clear this state on the transaction abort,
maybe I will raise this as a separate issue?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
test.sql
Description: application/sql
On Tue, Oct 5, 2021 at 4:08 PM Simon Riggs wrote:
>
> On Mon, 27 Sept 2021 at 06:52, Amit Kapila wrote:
> >
> > On Thu, Sep 23, 2021 at 11:11 AM Dilip Kumar wrote:
> > >
> > > On Thu, Sep 23, 2021 at 10:04 AM Sadhuprasad Patro
> > > wrote:
>
On Mon, Oct 4, 2021 at 2:51 PM Dilip Kumar wrote:
I have implemented the patch with approach2 as well, i.e. instead of
scanning the pg-class, we scan the directory.
IMHO, we have already discussed most of the advantages and
disadvantages of both approaches so I don't want to mention those
again
On Mon, Sep 27, 2021 at 12:23 PM Dilip Kumar wrote:
>
>
> Open question:
> - Scan pg_class vs scan directories
> - Whether to retain the old created database mechanism as option or not.
I have done some code improvement in 0001 and 0002.
--
Regards,
Dilip Kumar
Ent
On Sat, Oct 2, 2021 at 8:10 PM Alvaro Herrera wrote:
>
> On 2021-Oct-02, Dilip Kumar wrote:
>
> > I have written two patches, Approach1 is as you described using a
> > static boolean and Approach2 as a local variable to XLogAssembleRecord
> > as described by Amit, att
iable and functions as per the actual usage.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 3d4fb94fdeef2ae46511291f144b6305c9eea9f7 Mon Sep 17 00:00:00 2001
From: Dilip Kumar
Date: Sat, 2 Oct 2021 15:21:52 +0530
Subject: [PATCH] Refactor code for logging the top transaction id in
On Fri, Oct 1, 2021 at 12:42 PM Michael Paquier wrote:
>
> On Mon, Sep 13, 2021 at 05:10:22PM +0530, Dilip Kumar wrote:
> > I haved rebased the patch.
>
> Please note that the patch does not apply. FWIW, I still don't think
> that this is a good idea to have that. I don
ows, 10 columns and 4 threads, and queue size 64k. In
my performance machine, I tried to run this test multiple times but on
the head, it is taking ~2000 ms whereas with the patch it is ~1500 ms,
so I am not able to reproduce this. So it would be good if you can
run only this specific test and repeat it a couple of times on your
performance machine.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
time is very low for 64k queue size and then
again the execution time increased with 256k queue size and then
follow the pattern. So this particular dip in the execution time on
the head looks a bit suspicious to me. I mean how could we justify
this sudden big dip in execution time w.r.t the other
en disk change.
Open question:
- Scan pg_class vs scan directories
- Whether to retain the old created database mechanism as option or not.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
v3-0002-Extend-relmap-interfaces.patch
Description: Binary data
v3-0003-Refactor-index_co
On Sun, Sep 26, 2021 at 11:21 AM Dilip Kumar wrote:
>
> On Sat, Sep 25, 2021 at 2:18 AM Tomas Vondra
> wrote:
> >
> > On 9/24/21 7:08 PM, Robert Haas wrote:
> > > On Fri, Sep 24, 2021 at 3:50 AM Dilip Kumar wrote:
> > >> Tomas, can you share your te
On Sat, Sep 25, 2021 at 2:18 AM Tomas Vondra
wrote:
>
> On 9/24/21 7:08 PM, Robert Haas wrote:
> > On Fri, Sep 24, 2021 at 3:50 AM Dilip Kumar wrote:
> >> Tomas, can you share your test script, I would like to repeat the same
> >> test in my environment and
On Fri, Sep 24, 2021 at 1:30 AM Tomas Vondra
wrote:
>
> On 9/23/21 9:31 PM, Robert Haas wrote:
> > On Wed, Sep 8, 2021 at 2:06 AM Dilip Kumar wrote:
> >> But I am attaching both the patches in case you want to play around.
> >
> > I don't really see any reason
ement for RI and row filter
is orthogonal and if some columns are common then we can log only
once?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
some columns to RI because they wanted to use
the row filter on that. Now suppose we remove that limitation and we
somehow make these changes orthogonal to RI, i.e. if we have a row
filter on some column then we WAL log it, so now the only extra cost
we are paying is to just WAL log
I have tested with
different thresholds and it appeared that 1/4 of the queue size works
best. But I will do more detailed testing and share the results.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
ing enable_hashjoin =off is a solution, this can
happen with merge join or the nested loop join with materialized node,
in all such cases join filter can not be pushed down to the inner node
because the outer node will not start to scan until we
materialize/sort/hash the inner node. But yeah if we
On Wed, Sep 22, 2021 at 9:20 AM Amit Kapila wrote:
>
> On Wed, Sep 22, 2021 at 6:42 AM Ajin Cherian wrote:
> >
> > On Tue, Sep 21, 2021 at 9:42 PM Dilip Kumar wrote:
> > >
> > > On Tue, Sep 21, 2021 at 4:29 PM Dilip Kumar wrote:
> > >
On Tue, Sep 21, 2021 at 4:29 PM Dilip Kumar wrote:
> Some more comments,
>
> In pgoutput_row_filter_update(), first, we are deforming the tuple in
> local datum, then modifying the tuple, and then reforming the tuple.
> I think we can surely do better here. Currently, yo
On Tue, Sep 21, 2021 at 2:34 PM Amit Kapila wrote:
>
> On Tue, Sep 21, 2021 at 11:16 AM Dilip Kumar wrote:
> >
> > On Tue, Sep 21, 2021 at 10:41 AM Amit Kapila
> > wrote:
> > >
> > I think the point is if for some expression some
> > &g
filter for the oldtuple to
> > be just (a>10) then also do we need to deform?
> >
>
> Without deforming, how will you determine which columns are part of
> the old tuple?
Okay, then we might have to deform, but at least are we ensuring that
once we have deform th
me worst-case
scenarios, e.g. we have 10 text column and 1 int column in the REPLICA
IDENTITY and only the int column get updated and all the text column
are not updated, and you have a filter on all the columns.
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
e to just validate the
attributes which are actually modified and remaining unchanged and new
values will anyway get validated in the new tuple.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
order.
>
> There was a typo in suggested code above. It should be:
>
> + if (force_flush || mqh->mqh_send_pending > (mq->mq_ring_size >> 2))
Done
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From b111756f7136f3e0065a089a8616ad77b9963935 Mon Sep 17 00:00:00 2001
Fro
On Wed, Sep 8, 2021 at 4:41 PM Dilip Kumar wrote:
Based on various suggestions, I have some more experiments with the patch.
1) I have measured the cache misses count and I see a ~20% reduction
in cache misses with the patch (updating shared memory counter only
after we written certain amount
On Mon, Sep 13, 2021 at 9:42 PM Robert Haas wrote:
>
> On Mon, Sep 13, 2021 at 7:19 AM Dilip Kumar wrote:
> > Seems like nothing has been done about the issue reported in [1]
> >
> > This one line change shall fix the issue,
>
> Oops. Try this version.
T
On Fri, Sep 10, 2021 at 9:54 PM Jaime Casanova
wrote:
> > I will do that early next week.
> >
>
> Great! I'm marking the patch as "waiting on author".
> Thanks for keep working on this.
>
I haved rebased the patch.
--
Regards,
Dilip Kumar
EnterpriseDB
rward_end_archive(sink);
}
[1]
https://www.postgresql.org/message-id/CAFiTN-uhg4iKA7FGWxaG9J8WD_LTx655%2BAUW3_KiK1%3DSakQy4A%40mail.gmail.com
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
501 - 600 of 1635 matches
Mail list logo
