Maybe a setting similar to max_wal_size could be better for that?
+1
Thanks
Peter Eisentraut 于2024年7月25日周四 21:31写道:
> On 25.07.24 13:09, Heikki Linnakangas wrote:
> >> However, if there is no more disaster threshold at 2^31, what is the
> >> guidance for setting these? Or more radically, why
Hi Richard Guo
Is it necessary to add some comments here?
+ if (!innerpath->parallel_safe ||
+ !bms_is_empty(PATH_REQ_OUTER(innerpath)))
+ continue;
+
+ if (matched_path != NULL &&
+ compare_path_costs(matched_path, innerpath, TOTAL_COST) <= 0)
+ continue;
+
+ matched_path = innerpath;
at Alibaba
Best Regards,
feichanghong 于2024年7月8日周一 12:42写道:
> Hi wenhui,
>
> On Jul 8, 2024, at 12:18, wenhui qiu wrote:
>
> Hi feichanghong
> I don't think it's acceptable to introduce a patch to fix a problem
> that leads to performance degradation, or can we
Hi feichanghong
I don't think it's acceptable to introduce a patch to fix a problem
that leads to performance degradation, or can we take tom's suggestion to
optimise PreCommit_on_commit_actions? I think it to miss the forest for
the trees
Best Regards,
feichanghong 于2024年7月8日周一 10:35写道:
Hi feichanghong
Thanks for updating the patch ,I think could be configured as a GUC
parameter,PostgreSQL has too many static variables that are written to
death and explicitly stated in the code comments may later be designed as
parameters. Now that more and more applications that previously
Hi Richard Guo
Thank you for updating the patch.Tested on v8 , It looks good to me
Thanks
Richard Guo 于2024年7月4日周四 17:18写道:
> On Fri, Jun 28, 2024 at 3:21 PM Richard Guo
> wrote:
> > On Fri, Jun 28, 2024 at 2:54 PM Richard Guo
> wrote:
> > > I've refined this test case further to make
Hi Tom ,Matthias
Thank you for your explanation.Maybe future compilers will be able to
do intelligent prediction?
Thanks
Tom Lane 于2024年6月30日周日 23:23写道:
> Matthias van de Meent writes:
> > On Sun, 30 Jun 2024, 15:56 wenhui qiu, wrote:
> >> if (unlikely(ExecutorRun_h
Hi Hackers
When I saw this document:https://en.wikipedia.org/wiki/Branch_predictor,
I thought of Linux likely() vs unlikely() and thus thought that there are
some code segments in src/backend/executor/execMain.c that can be optimized.
For example :
if (ExecutorStart_hook)
(*ExecutorStart_hook)
Hi Japin Li
Thank you for your reviewing ,This way the notes are more accurate and
complete. Thanks also to the author for updating the patch ,I also tested
the new patch ,It looks good to me
Regrads
Japin Li 于2024年6月25日周二 08:51写道:
> On Mon, 24 Jun 2024 at 17:59, Richard Guo wrote:
> >
Hi Richard
Thank you so much for your tireless work on this,I see the new version
of the patch improves some of the comments .I think it can commit in July
Thanks
On Thu, 25 Apr 2024 at 11:28, Richard Guo wrote:
> Here is another rebase with a commit message to help review. I also
>
Hi Maxim Orlov
Thank you so much for your tireless work on this. Increasing the WAL
size by a few bytes should have very little impact with today's disk
performance(Logical replication of this feature wal log is also increased a
lot, logical replication is a milestone new feature, and the
Agree +1,From a dba perspective, I would prefer that this parameter can be
dynamically modified, rather than adding a new parameter,What is more
difficult is how to smoothly reach the target value when the setting is
considered to be too large and needs to be lowered.
Regards
On Tue, 16 Apr
Hi Aleksander Alekseev
Could you take a look at the patch (
https://commitfest.postgresql.org/47/4284/),How about your opinion
Thanks
On Tue, 12 Mar 2024 at 21:41, Aleksander Alekseev
wrote:
> Hi Andrey,
>
> > > If you need any help please let me know.
> >
> > Aleksander, I would
Hi Alena Rybakina
For merge join
+ /*
+ * For now we do not support RIGHT_SEMI join in mergejoin.
+ */
+ if (jointype == JOIN_RIGHT_SEMI)
+ {
+ *mergejoin_allowed = false;
+ return NIL;
+ }
+
Tanks
On Wed, 6 Mar 2024 at 04:10, Alena Rybakina
wrote:
> To be honest, I didn't see it in the code,
Hi Richard
Agree +1 ,I think can push now.
Richard
On Tue, 5 Mar 2024 at 10:44, Richard Guo wrote:
>
> On Tue, Jan 30, 2024 at 2:51 PM Alena Rybakina
> wrote:
>
>> I have reviewed your patch and I think it is better to add an Assert for
>> JOIN_RIGHT_SEMI to the ExecMergeJoin and
HI Richard
Now it is starting the last commitfest for v17, can you respond to
Alena Rybakina points?
Regards
On Thu, 8 Feb 2024 at 13:50, wenhui qiu wrote:
> Hi Alena Rybakina
> I saw this code snippet also disable mergejoin ,I think it same effect
> + /*
> + * F
efault value is 4, which corresponds to 16 partitions, and
the maximum is 8. This parameter can only be set in the postgresql.conf file
or on the server command line.
Best wish
On Tue, 20 Feb 2024 at 21:55, Tomas Vondra
wrote:
> Hi,
>
> On 2/20/24 03:16, wenhui qiu wrote:
> >
.
`
wenhui qiu 于2024年2月20日周二 09:36写道:
> Hi Japlin Li
>Thank you for such important information ! Got it
>
> Japin Li 于2024年2月19日周一 10:26写道:
>
>>
>> On Mon, 19 Feb 2024 at 00:56, Tomas Vondra
>> wrote:
>> > On 2/18/24 03:30, Li Jap
Hi Japlin Li
Thank you for such important information ! Got it
Japin Li 于2024年2月19日周一 10:26写道:
>
> On Mon, 19 Feb 2024 at 00:56, Tomas Vondra
> wrote:
> > On 2/18/24 03:30, Li Japin wrote:
> >>
> >> I find it seems need to change MAX_SIMUL_LWLOCKS if we enlarge the
> NUM_BUFFER_PARTITIONS,
, but the
result report is in Chinese
Best wishes
Heikki Linnakangas 于2024年2月8日周四 19:26写道:
> On 08/02/2024 12:17, wenhui qiu wrote:
> > HI hackers
> > When I read this text in this document there is a paragraph in
> > it(https://www.interdb.jp/pg/pgsql08/03.html
> &
HI hackers
When I read this text in this document there is a paragraph in it(
https://www.interdb.jp/pg/pgsql08/03.html)
/*
The BufMappingLock is split into partitions to reduce contention in the
buffer table (the default is 128 partitions). Each BufMappingLock partition
guards a portion of
Hi Alena Rybakina
I saw this code snippet also disable mergejoin ,I think it same effect
+ /*
+ * For now we do not support RIGHT_SEMI join in mergejoin.
+ */
+ if (jointype == JOIN_RIGHT_SEMI)
+ {
+ *mergejoin_allowed = false;
+ return NIL;
+ }
+
Regards
Alena Rybakina 于2024年1月30日周二 14:51写道:
Hi vignesh C
Many thanks, I have marked it to "ready for committer"
Best wish
vignesh C 于2024年1月23日周二 10:56写道:
> On Mon, 22 Jan 2024 at 11:27, wenhui qiu wrote:
> >
> > Hi vignesh CI saw this path has been passed (
> https://cirrus-ci.com/build/6
Hi vignesh CI saw this path has been passed (
https://cirrus-ci.com/build/6109321080078336),can we push it?
Best wish
Richard Guo 于2024年1月9日周二 18:49写道:
>
> On Sun, Jan 7, 2024 at 3:03 PM vignesh C wrote:
>
>> One of the tests in CFBot has failed at [1] with:
>> - Relations: (public.ft1
AND i4.f1 = a.tenthous;
QUERY PLAN
Hash Join
Hash Cond: (a.tenthous = i4.f1)
-> Seq Scan on tenk1 a
Filter: (SubPlan 1)
SubPlan 1
->
Hi Junwang Zhao
Agree +1
Best whish
Junwang Zhao 于2023年12月20日周三 10:35写道:
> On Wed, Dec 20, 2023 at 9:58 AM Thomas wen
> wrote:
> >
> > Hi Junwang Zhao
> > #should we invalidate lock_timeout? Or maybe just document this.
> > I think you mean when lock_time is greater than
Hi Pavel Borisov
Many thanks
Best whish
Pavel Borisov 于2023年12月15日周五 17:13写道:
> Hi, Wenhui!
>
> On Fri, 15 Dec 2023 at 05:52, wenhui qiu wrote:
>
>> Hi Maxim Orlov
>> Good news,xid64 has achieved a successful first phase,I tried to
>>
Hi Richard Guo I see that the test samples are all (exists)
subqueries ,I think semi join should also support ( in) and ( any)
subqueries. would you do more test on ( in) and ( any) subqueries?
Best whish
Hi Maxim Orlov
Good news,xid64 has achieved a successful first phase,I tried to change
the path status (https://commitfest.postgresql.org/43/3594/) ,But it seems
incorrect
Maxim Orlov 于2023年12月13日周三 20:26写道:
> Hi!
>
> Just to keep this thread up to date, here's a new version after recent
>
29 matches
Mail list logo