Hi~
> Thanks for looking at this. Yes, the WAL writers can zero out flushed
> buffers before WALReadFromBuffers gets to them. However,
> WALReadFromBuffers was intentionally designed as an opportunistic
> optimization - it's a "try this first, quickly" approach before
> falling back to reading fro
Hi~
> I purpose a patch which calls smgrdestroyall() when redo each
> XLOG_CHECKPOINT_ONLINE, so that it can keep the same frequency of calling
> smgrdestroyall() as background processes on primary. I don't call it for
> XLOG_CHECKPOINT_SHUTDOWN because the process is about to exit so that the
> m
Hi~
> Agree with that. Maybe we can call smgrdestroyall in startup process when
> replaying CHECKPOINT records, just like bgwriter/checkpointer, which free
> all smgr objects after any checkpoint.
That seems reasonable, in that case a startup process would behave just the
same as bgwriter or chec
Hi~
> On Sat, Aug 16, 2025 at 12:50 AM Jingtang Zhang
> wrote:
>> Back to v17, commit 21d9c3ee gave SMgrRelation a well-defined lifetime, and
>> smgrclose nolonger removes SMgrRelation object from the hashtable, leaving
>> the work to smgrdestroyall. But I find a
Hi~
Thanks for looking.
> DropRelationFiles() is also called by FinishPreparedTransaction(). At
> first I thought that might be a problem too, but looking a bit more
> closely and trying it out... if a prepared transaction dropped a
> table, then it called RelationDropStorage(), RelationCloseSmg
Hi~ hackers
Back to v17, commit 21d9c3ee gave SMgrRelation a well-defined lifetime, and
smgrclose nolonger removes SMgrRelation object from the hashtable, leaving
the work to smgrdestroyall. But I find a place that relies on the removing
behavior previously, but is still calling smgrclose.
Startu
> Do any of you have a specific wording in mind?
'Like when FPW is on …' would be okay, or '(e.g., when FPW is on …)'
would be formal?
--
Regards, Jingtang
Hi~
> FPWs are used here and there in a lot of places, like "FPI for hint". And
> indexes are build using FPI for many years, it did not start with 17...
Yeah, my fault. Creating index prior to v17 was also using log_newpages.
—
Regards, Jingtang
Hi hackers~
I find the specification of wal_compression in our docs a little bit confusing
for it 'compress full page images when FPW is on or during a base backup',
which was true before v17. Since v17, we will also use full page images for
creating index or table rewrites through bulk write, so
Hi hackers~
Recently when I was debugging with pg_waldump, I just want to filter out
all the records about a specific relfilelocator, so I used -R T/D/R.
I do get records like FPI, but not SMGR_CREATE / SMGR_TRUNCATE. Quick
search of code tells me that pg_waldump would only keep records with
block
Hi, Daniil Davydov.
Thanks for sharing your patch!
It was quite a while since I last looked at the patch. I've tested it again,
and still get regression on patched version where a table has many columns.
And it is totally CPU-bounded on tts_virtual_copyslot.
Unpatched version:
1 col:
Time: 8909.
Hi, Nathan.
I just realized that I almost forgot about this thread :)
> The result looks great, but the discussion in [0] shows that the result may
> vary among different ARM chips. Could you provide the chip model of this
> test? So that we can do a cross validation of this patch. Not sure if co
Hi~Just found 'relam' field is assigned twice during relcache initialization. Wehave a specific area for initialization AM related stuff several lines later: /* * initialize the table am handler */ relation->rd_rel->relam = HEAP_TABLE_AM_OID; relation->rd_tableam = GetHeapamTableAmRoutine();so pr
Hi~
I did some performance test these days, and I have some findings.
From the archive months ago, I found there were discussions about which type
of TupleTableSlot to use for buffering tuples. A single column mat view was
used for evaluation. Finally we used virtual one.
However when I test wit
Hi~
Sorry for multiple comments in separate mail. Just found that the initialization
seems redundant since we have used palloc0?
> +istate = (HeapInsertState *) palloc0(sizeof(HeapInsertState));
> +istate->bistate = NULL;
> +istate->mistate = NULL;
---
Regards, Jingtang
Oh, another comments for v24-0001 patch: we are in heam AM now, should we use
something like HEAP_INSERT_BAS_BULKWRITE instead of using table AM option,
just like other heap AM options do?
> + if ((state->options & TABLE_INSERT_BAS_BULKWRITE) != 0)
> + istate->bista
Hi! Glad to see update in this thread.
Little question about v24 0002 patch: would it be better to move the
implementation of TableModifyIsMultiInsertsSupported to somewhere for table
AM
level? Seems it is a common function for future use, not a specific one for
matview.
---
Regards, Jingtang
Hi~
Upon closer inspection, I noticed that we don't implement a custom
> TAS_SPIN() for this architecture, so I quickly hacked together the attached
> patch and ran a couple of benchmarks that stressed the spinlock code. I
> found no discussion about TAS_SPIN() on ARM in the archives, but I did
>
Hi all.
I've been back to this patch for a while recently. I witness that if a WAL
writer works fast, the already flushed WAL buffers will be zeroed out and
re-initialized for future use by AdvanceXLInsertBuffer in
XLogBackgroundFlush, so that WALReadFromBuffers will miss even though the
space of
Hi hackers. I found a strange point when I was reading the heapam
handlers of table access method, where heapam_tuple_insert and several
handlers explicitly assign t_tableOid of the tuple to be operated,
while later the t_tableOid is assigned again by like heap_prepare_insert or
so. Is it redundant
Thanks, Tomas.
> Theoretically, yes, we could make max_changes_in_memory a GUC, but it's
> not clear to me how would that help 12/13, because there's ~0% chance
> we'd backpatch that ...
What I mean is not about back-patch work. Things should happen on publisher
side?
Consider when the publisher
Hi hackers.
Recently I came to an issue about logical replicating very big
transactions. Since we already have logical_decoding_work_mem to keep
the memory usage, there is no risk of OOM during decoding. However, the
memory usage still goes out of control in 'Tuples' memory context of
reorder buff
Hi, Bharath. I've been testing this. It's cool. Is there any way we could
monitor the hit rate about directly reading from WAL buffers by exporting
to some views?
---
Regards, Jingtang
Michael Paquier 于2023年9月8日周五 13:42写道：
Thanks, Michael~
> The assignment of num_phys_attrs could be kept at the same place as
> on HEAD, a bit closer to the palloc0() where it is used.
>
Agreed with this principle. Patch is modified and attached.
--
Jingtang
v2-0001-Remove-redundant-assignme
Hi all, I was reading code of COPY FROM and I found some suspicious
redundant assignment for tuple descriptor and number of attributes. Is
it a behavior on purpose, or an accidently involved by the refactor in
c532d15? Patch is attached.
0001-Remove-redundant-assignment-in-copyfrom.patch
Descript
me voice from kernel hackers, thanks~
--
Best Regards,
Jingtang
——
Jingtang Zhang
E-Mail: mrdrivingd...@gmail.com
GitHub: @mrdrivingduck
Sent from Microsoft Surface Book 2.
I see, thank you.
Tom Lane 于2022年7月9日周六 03:35写道：
> Jingtang Zhang writes:
> > Recently, when I was developing some function about INSERT ... ON
> CONFLICT,
> > I used test cases in `src/test/regress/sql/insert_conflict.sql` to
> evaluate
> > my function. When I copy
regression, but
would it be better to use space here to avoid this confusing situation?
Since other part of this case are all using spaces.
Never mind my opinion as a beginner, thanks.
Jingtang Zhang
0001-Fix-two-tabs-are-regarded-as-auto-completion-in-test.patch
Description: Binary data
28 matches
Mail list logo
