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
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
me voice from kernel hackers, thanks~
--
Best Regards,
Jingtang
——
Jingtang Zhang
E-Mail: mrdrivingd...@gmail.com
GitHub: @mrdrivingduck
Sent from Microsoft Surface Book 2.
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
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
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
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
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
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 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~
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~
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
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! 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
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~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, 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, 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 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
19 matches
Mail list logo
