t; comments.
Does this patch set work independently or it has dependency on the
patches on the other thread "Smoothing the subtrans performance
catastrophe"? Because in this patch I see no code where we are
changing anything to control the access of SubTransGetParent() from
SubTransGetTopmostTransactionId()?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Sun, Aug 7, 2022 at 9:47 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-08-07 09:24:40 +0530, Dilip Kumar wrote:
> > On Sat, Aug 6, 2022 at 9:36 PM Tom Lane wrote:
> > >
> > > Dilip Kumar writes:
> > > > On Fri, Aug 5, 2022 at 10:43 AM Dilip Kuma
Transaction() then it will just return the same xid
if the parent is not set for it. And now if we search this in the
snapshot->xip array then we will get the wrong answer?
So I still think some adjustment is required in XidInMVCCSnapdhot()
such that we first search the snapshot->subxip arr
On Tue, Aug 9, 2022 at 8:51 PM Robert Haas wrote:
>
> On Fri, Aug 5, 2022 at 3:25 AM Dilip Kumar wrote:
> > I think even if we start the range from the 4 billion we can not avoid
> > keeping two separate ranges for system and user tables otherwise the
> > next upgrade wh
On Wed, Aug 10, 2022 at 6:31 PM Simon Riggs
wrote:
>
> On Wed, 10 Aug 2022 at 08:34, Dilip Kumar wrote:
> >
> > Am I still missing something?
>
> No, you have found a dependency between the patches that I was unaware
> of. So there is no bug if you apply both patche
On Thu, Aug 11, 2022 at 10:58 AM Dilip Kumar wrote:
>
> On Tue, Aug 9, 2022 at 8:51 PM Robert Haas wrote:
> >
> > On Fri, Aug 5, 2022 at 3:25 AM Dilip Kumar wrote:
> > > I think even if we start the range from the 4 billion we can not avoid
> > > keeping two
On Wed, Aug 25, 2021 at 5:49 PM Amit Kapila wrote:
> On Tue, Aug 24, 2021 at 3:55 PM Dilip Kumar wrote:
> >
> > On Tue, Aug 24, 2021 at 12:26 PM Amit Kapila
> wrote:
> >
>
> The first patch looks good to me. I have made minor changes to the
> attached p
14 but I see an argument to commit this for PG-14 to
> keep the code (APIs) consistent. What do you think? Does anybody else
> have any opinion on this?
>
>
IMHO, this is a fair amount of refactoring and this is actually an
improvement patch so we should push it to v15.
--
Regards,
Dil
On Fri, Aug 27, 2021 at 10:56 AM houzj.f...@fujitsu.com
wrote:
>
> On Thu, Aug 26, 2021 2:18 PM Dilip Kumar wrote:
>
> > The patch looks good to me, I have rebased 0002 atop
> > this patch and also done some cosmetic fixes in 0002.
>
> Here are some comment
On Tue, Aug 24, 2021 at 8:48 PM Robert Haas wrote:
> On Fri, Aug 6, 2021 at 4:31 AM Dilip Kumar wrote:
> > Results: (query EXPLAIN ANALYZE SELECT * FROM t;)
> > 1) Non-parallel (default)
> > Execution Time: 31627.492 ms
> >
> > 2) Parallel with 4 workers (for
On Tue, Aug 31, 2021 at 7:39 AM houzj.f...@fujitsu.com <
houzj.f...@fujitsu.com> wrote:
> From Mon, Aug 30, 2021 2:15 PM Masahiko Sawada
> wrote:
> > On Fri, Aug 27, 2021 at 3:34 PM Dilip Kumar
> wrote:
> > >
> > > On Fri, Aug 27, 2021 at 10:5
On Tue, Aug 31, 2021 at 3:20 PM Amit Kapila wrote:
>
> On Fri, Aug 27, 2021 at 12:04 PM Dilip Kumar wrote:
> >
>
> Few comments on v6-0002*
> =
> 1.
> -BufFileDeleteFileSet(FileSet *fileset, const char *name)
> +BufFileDeleteFileSet(File
On Wed, Sep 1, 2021 at 5:23 PM Amit Kapila wrote:
> On Wed, Sep 1, 2021 at 1:53 PM Dilip Kumar wrote:
> >
>
> The latest patch looks good to me. I have made some changes in the
> comments, see attached. I am planning to push this tomorrow unless you
> or others have any com
On Tue, Jul 6, 2021 at 3:00 PM Dilip Kumar wrote:
>
> On Fri, Jun 18, 2021 at 12:50 AM Robert Haas wrote:
> >
> > On Thu, Jun 17, 2021 at 2:48 PM Andres Freund wrote:
> > > Or do you mean that looking at the filesystem at all is bypassing shared
> > > buf
ying the relation
e.g. index_copy_data(), heapam_relation_copy_data(). So the current system
as it stands, we can not claim that we are designing something for the
first time where we are bypassing the shared buffers. So if we are
thinking that bypassing the shared buffers is hackish and we don't want to
use it for the new patches then lets avoid it completely even while
identifying the relfilenodes to be copied.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Sep 2, 2021 at 8:52 PM Robert Haas wrote:
> On Thu, Sep 2, 2021 at 2:06 AM Dilip Kumar wrote:
> > 0003- The main patch for WAL logging the created database operation.
>
> Andres pointed out that this approach ends up accessing relations
> without taking a lock on the
On Sat, Sep 4, 2021 at 3:24 AM Andres Freund wrote:
> Hi,
>
> On 2021-09-03 14:25:10 +0530, Dilip Kumar wrote:
> > Yeah, we can surely lock the relation as described by Robert, but IMHO,
> > while creating the database we are already holding the exclusive lock on
> > t
On Mon, Sep 6, 2021 at 1:58 AM Andres Freund wrote:
> On 2021-09-05 14:22:51 +0530, Dilip Kumar wrote:
> But these directly operate on the buffers and In my patch, whether we are
> > reading the pg_class for identifying the relfilenode or we are copying
> the
> > relation
On Mon, Sep 6, 2021 at 11:17 AM Dilip Kumar wrote
>
> Okay, that makes sense. Infact for using the shared buffers for the
> destination database's relation we don't even have the locking issue,
> because that database is not yet accessible to anyone right?
>
Based on a
ge is re-computed. I think the correct fix
> would be that in the beginning we just compute the change_size by
> ReorderBufferChangeSize and then after re-computing the change, we
> just subtract the old change_size and add the new change_size. What do
> you think?
>
Yeah,
d
add/subtract that size. Logically, that is what we are actually trying to
do right? i.e. replacing old change with the new change.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Sep 7, 2021 at 8:38 AM Amit Kapila wrote:
> On Mon, Sep 6, 2021 at 9:14 PM Dilip Kumar wrote:
> >
> > On Mon, Sep 6, 2021 at 8:54 PM Drouvot, Bertrand
> wrote:
> >>
> >> Thanks for your feedback!
> >>
> >> That seems indeed more log
t; remove the entire table from publication as Rahila is proposing.
>
> I think removing just a particular column can break the replication
> for Updates and Deletes if the removed column is part of replica
> identity.
>
But how this is specific to this patch, I think the behavior should be the
same as what is there now, I mean now also we can drop the columns which
are part of replica identity right.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
nly caller for this function.
> >
>
> Why can't we simply ignore it in ReorderBufferChangeMemoryUpdate() as
> we are doing now?
>
Yeah right, we can actually do that, it doesn't matter even if we are
passing the size from outside.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
r intended to to propose anything. My most of the latest
performance data I sent with only
"v1-0001-Optimize-parallel-tuple-send-shm_mq_send_bytes.patch" and with
default tuple queue size.
But I am attaching both the patches in case you want to play around.
--
Regards,
Dilip Kumar
Ent
ain with this.
>
> We also should probably split the read-mostly data in shm_mq (ring_size,
> detached, ring_offset, receiver, sender) into a separate cacheline from the
> read/write data. Or perhaps copy more info into the handle, particularly
> the
> ringsize (or mask).
>
Good suggestion, I will do some experiments around this.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Sep 8, 2021 at 11:26 AM Ajin Cherian wrote:
> On Wed, Aug 11, 2021 at 10:45 PM Dilip Kumar
> wrote:
>
> > Yeah we can avoid that by detecting any toasted replica identity key
> > in HeapDetermineModifiedColumns, check the attached patch.
> >
>
> I had
On Wed, Sep 8, 2021 at 12:03 PM Andres Freund wrote:
> Hi,
>
> On 2021-09-08 11:45:16 +0530, Dilip Kumar wrote:
> > On Wed, Sep 8, 2021 at 3:08 AM Andres Freund wrote:
> >
> >
> > > Looking at this profile made me wonder if this was a build without
> &g
On Wed, Sep 8, 2021 at 3:28 PM Tomas Vondra
wrote:
On 9/8/21 9:40 AM, Dilip Kumar wrote:
>
> > Maybe it can be misleading sometimes, but I feel sometimes it is more
> > informative compared to the optimized build where it makes some function
> > inline, and then it b
On Fri, 10 Sep 2021 at 10:40 AM, Jaime Casanova <
jcasa...@systemguards.com.ec> wrote:
> On Mon, Jul 19, 2021 at 01:24:03PM +0530, Dilip Kumar wrote:
> > On Sun, Jul 18, 2021 at 9:15 PM Dilip Kumar
> wrote:
> > >
> > > On Wed, Jul 14, 2021 at 5:35 PM vignesh C
identify the relfilenode and then copy it block by block, so
maybe this approach will not make anyone unhappy because it is not any
worse than the current system.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
bbsink_forward_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
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
Enterpr
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 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
; 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
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
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
able to modify the 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
on
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
> > > values
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, you are
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:
> > >
> >
#x27;t think suggesting 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 n
ith 250 bytes tuple size, 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
ed users to add 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 t
ow the WAL logging requirement 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
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 r
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 with
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
s one.
Changed, now WAL first and then 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:
lumn and
thread the execution 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
rows, 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
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 d
ed the variable 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 transact
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
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 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
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:
>
maintain that sanity right? That means at least on the NEW rows
we should apply the filter, IMHO. Said that, now if there is any row
inserted which were satisfying the filter and replicated, if we update
it with the new value which is not satisfying the filter then it will
not be replicated, I think that makes sense because if an insert is
not sending any row to a replica which is not satisfying the filter
then why update has to do that, right?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jun 22, 2021 at 1:37 PM Michael Paquier wrote:
>
> On Tue, Jun 22, 2021 at 11:05:22AM +0530, Dilip Kumar wrote:
> > IMHO there is certainly a use case, basically, if we compress the data
> > so that we can avoid storing it externally. Now suppose for some
> >
LD row as it was not satisfying the condition but the
modified row will be sent as an INSERT operation because this is
satisfying the condition?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
or updates
Right
> but I still suggest completing the analysis (or at least spend some
> more time) Tomas and I requested in the few emails above and then
> conclude on this point.
+1
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jul 16, 2021 at 8:57 AM Amit Kapila wrote:
>
> On Wed, Jul 14, 2021 at 4:30 PM Dilip Kumar wrote:
> >
> > On Wed, Jul 14, 2021 at 3:58 PM Tomas Vondra
> > wrote:
> > >
> > > Is there some reasonable rule which of the old/new tuples (or both
could not read COPY data: server closed the
> connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
>
I think the problem is that bbsink_gzip_end_archive() is not
forwarding the end request to the next bbsink.
On Wed, Jul 14, 2021 at 5:35 PM vignesh C wrote:
>
> On Thu, May 6, 2021 at 7:24 PM Dilip Kumar wrote
>
> The patch does not apply on Head anymore, could you rebase and post a
> patch. I'm changing the status to "Waiting for Author".
Okay, I will rebase and send
On Sun, Jul 18, 2021 at 9:15 PM Dilip Kumar wrote:
>
> On Wed, Jul 14, 2021 at 5:35 PM vignesh C wrote:
> >
> > On Thu, May 6, 2021 at 7:24 PM Dilip Kumar wrote
> >
> > The patch does not apply on Head anymore, could you rebase and post a
> > patch. I&#
, if the old or the new row do not pass the
> > filter, respectively. That way, the databases would remain consistent.
Yeah, I think this is the best way to keep the data consistent.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Jul 16, 2021 at 12:43 PM Dilip Kumar wrote:
>
> On Mon, Jul 12, 2021 at 5:51 PM tushar wrote:
> >
> > On 7/8/21 9:26 PM, Robert Haas wrote:
> > > Here at last is a new version.
> > Please refer this scenario ,where backup target using
> > --s
On Mon, Jul 19, 2021 at 6:02 PM tushar wrote:
>
> On 7/16/21 12:43 PM, Dilip Kumar wrote:
> > I think the problem is that bbsink_gzip_end_archive() is not
> > forwarding the end request to the next bbsink. The attached patch so
> > fix it.
>
> Thanks Dilip. Report
true and after that you
can pass this as inout parameter to pgarch_readyXlog() there in it can
be conditionally set to false once we get some segment and whenever
the timeline switch we can set it back to the true.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
ca identity key or
we need to use REPLICA IDENTITY FULL. I think that is what Tomas
wants to point out.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Jul 20, 2021 at 3:43 PM Tomas Vondra
wrote:
>
> Do we log the TOAST-ed values that were not updated?
No, we don't, I have submitted a patch sometime back to fix that [1]
[1] https://commitfest.postgresql.org/33/3162/
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, Jul 22, 2021 at 4:11 PM Amit Kapila wrote:
>
> On Thu, Jun 3, 2021 at 5:15 PM Dilip Kumar wrote:
> >
> > On Wed, Jun 2, 2021 at 7:23 PM Dilip Kumar wrote:
> > >
> > > On Wed, Jun 2, 2021 at 7:20 PM Kuntal Ghosh
> > > wrote:
> > >
On Thu, Jul 22, 2021 at 5:15 PM Amit Kapila wrote:
>
> On Tue, Jul 20, 2021 at 4:33 PM Dilip Kumar wrote:
> >
> > On Tue, Jul 20, 2021 at 3:43 PM Tomas Vondra
> > wrote:
> > >
> > > Do we log the TOAST-ed values that were not updated?
> >
> >
how are we
supposed to find the tuple on the subscriber side?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
g for the externally stored data otherwise it will be very
difficult to control that inside the expression evaluation.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
k for the
non-partitioned table if the user hasn't set it we should do automatic
safety checking and if the user has defined the safety externally then
we should respect that. And for the partitioned table, we will never
do the automatic safety checking and we should always respect what the
user has set.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
l_prohibited)
> + {
> + /* No need to hold ControlFileLock yet, we aren't up far enough */
> + ControlFile->wal_prohibited = false;
> + ControlFile->time = (pg_time_t) time(NULL);
> + UpdateControlFile();
> +
Is there some reason why we are forcing 'wal_prohibited
then it is must for providing an
infinite tuple queue (maybe using temp file) to avoid deadlock.
Note: POC patches are not attached, I will send them after some more
experiments and cleanup, maybe I will try to optimize the reader part
as well before sending them.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
nt to do so in this case pgstat_recv_resetcounter(), can send two
messages one for MyDatabaseOid which it is already doing, and another
message for the InvalidOid.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Aug 6, 2021 at 2:00 PM Dilip Kumar wrote:
>
> Experiment #1:
> As part of this experiment, I have modified the sender to keep the
> local copy of "mq_bytes_read" and "mq_bytes_written" in the local mqh
> handle so that we don't need to frequently re
'), if required to set 'relrewrite'. Additionally, let's add a
> test case if possible for this.
I agree with Amit, that setting relrewrite for the toast relation as
well is better as we can simply avoid processing the toast tuple as
well in such cases.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Aug 3, 2021 at 4:25 PM Amit Kapila wrote:
>
> On Tue, Jul 27, 2021 at 9:56 AM Dilip Kumar wrote:
>
> > Yeah, that's a big problem, seems like the expression evaluation
> > machinery directly going and detoasting the externally stored data
> > using so
an use that
to match the hash value for other key columns before accessing the
heap, as discussed here[1]. IMHO, this will further reduce the heap
access.
[1] https://www.postgresql.org/message-id/7192.1506527843%40sss.pgh.pa.us
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
ide what they want to
do.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
the docs[1].
Yeah we can avoid that by detecting any toasted replica identity key
in HeapDetermineModifiedColumns, check the attached patch.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 3879809bf1a995995dccf5064eb9282f72af0412 Mon Sep 17 00:00:00 2001
From: Dilip Kuma
//dev.mysql.com/doc/refman/8.0/en/index-btree-hash.html
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
While reading through the README of the hash index I noticed a grammar
error, the attached patch fixes the same.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 2760cd42e7f6354399d30ac56741268130f6e017 Mon Sep 17 00:00:00 2001
From: Dilip Kumar
Date: Thu, 12 Aug 2021 14
value of all the
columns then there should be a fewer overflow bucket, but IIUC, in
this patch bucket, is identified based on the hash value of the first
column only so there could be a lot of duplicates on the first column.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
x27;filesetlist'. I have attached a patch for the same.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
0001-Better-usage-of-sharedfileset-in-apply-worker.patch
Description: Binary data
. But with this suggestion, we will always
create the file as soon as we get the first subtransaction.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Tue, Aug 17, 2021 at 10:54 AM Amit Kapila wrote:
>
> On Mon, Aug 16, 2021 at 8:18 PM Dilip Kumar wrote:
> >
> > On Fri, Aug 13, 2021 at 9:29 PM Andres Freund wrote:
> >
> > > > I think we can extend this API but I guess it is better to then do it
> &g
gt; + SharedFileSetDelete(xidfileset, path, true);
> >
> > Without the patch it doesn't throw an error if not exist,
> > But with the patch, it pass error_on_failure=true to SharedFileSetDelete().
> >
>
> Don't we need to use BufFileDeleteShared instead of
> SharedFileSetDelete as you have used to remove the changes file?
Yeah, it should be BufFileDeleteShared.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
which are ending with Shared e.g.
BufFileCreateShared, BufFileOpenShared, should be converted to
BufFileCreate and
BufFileOpen respectively. And the input to these interfaces can be
converted to FileSet instead of SharedFileSet.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Wed, Aug 18, 2021 at 3:45 PM Dilip Kumar wrote:
>
> On Wed, Aug 18, 2021 at 11:24 AM Amit Kapila wrote:
> >
> > On Tue, Aug 17, 2021 at 4:34 PM Andres Freund wrote:
> > >
> > > On 2021-08-17 10:54:30 +0530, Amit Kapila wrote:
> > > > 5. How c
, those were internally used by buffile.c but now we have changed
buffile.c to directly use the fileset interfaces, so we better remove
them.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Mon, Aug 23, 2021 at 11:43 AM Amit Kapila wrote:
>
> On Mon, Aug 23, 2021 at 9:53 AM Dilip Kumar wrote:
> >
> > On Mon, Aug 23, 2021 at 9:11 AM houzj.f...@fujitsu.com
> > wrote:
> >
> > > 4)
> > > -extern File SharedFileSetCreate
r to what you've in 0002
> patch.
>
I have done handling in worker.c
On Mon, Aug 23, 2021 at 9:11 AM houzj.f...@fujitsu.com
wrote:
>
> On Sat, Aug 21, 2021 8:38 PM Dilip Kumar wrote:
>
> 1)
> + TempTablespacePath(tempdirpath, tablespace);
> +
the set is one or more directories which will eventually
> * be deleted.
> */
> void
> SharedFileSetInit(SharedFileSet *fileset, dsm_segment *seg)
>
> I think we can remove the part of the above comment where it says
> "Files will be distributed over ..." as that
attached patch addresses the issue by eliminating the need to
track VacuumPage(Hit/Miss/Dirty) counters in do_analyze_rel(), making
the global counters obsolete. This simplifies the code and improves
consistency.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
v1-0001-Remove
1201 - 1300 of 1734 matches
Mail list logo
