Re: make add_paths_to_append_rel aware of startup cost

-> Result > (8 rows) > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=2024-02-14%2000%3A01%3A03 Thanks for this information! I will take a look at this. -- Best Regards Andy Fan

Re: make add_paths_to_append_rel aware of startup cost

Andy Fan writes: > Thomas Munro writes: > >> On Thu, Oct 5, 2023 at 9:07 PM David Rowley wrote: >>> Thanks. Pushed. >> >> FYI somehow this plan from a8a968a8212e flipped in this run: >> >> === dumping >> /home/bf/bf-build/mylodon/HEAD/p

Re: [PATCH] Expose port->authn_id to extensions and triggers

bset of that. And applied. I found a compiler complaint of this patch. The attached fix that. -- Best Regards Andy Fan >From 9e8a3fb7a044704fbfcd682a897f72260266bd54 Mon Sep 17 00:00:00 2001 From: "yizhi.fzh" Date: Thu, 15 Feb 2024 16:46:57 +0800 Subject: [PATCH v1 1/1] Remov

Re: A new strategy for pull-up correlated ANY_SUBLINK

I double checked the patch, it looks good to me. -- Best Regards Andy Fan

Re: make add_paths_to_append_rel aware of startup cost

same conclusion here. > > So, if nobody has any better ideas, I'm just going to push the " and > t2.thousand = 0" adjustment. LGTM. -- Best Regards Andy Fan

Re: serial not accepted as datatype in ALTER TABLE ... ALTER COLUMN

int. So when we modify a column into serial, we need to modify the 'NULL value' and only to the default value at the RewriteTable stage. -- Best Regards Andy Fan >From 4485a9af33c9c7d493e23c2804bde4c15df0b79a Mon Sep 17 00:00:00 2001 From: "yizhi.fzh" Date: Sun, 18 Feb

Re: Properly pathify the union planner

not have those redundant checks in > pathkeys_useful_for_setop(), and I do want those functions to be as > similar as possible. So I think adjusting it in master is a good > idea. > > I've pushed your patch. > Thanks for the pushing! -- Best Regards Andy Fan

Re: serial not accepted as datatype in ALTER TABLE ... ALTER COLUMN

Ashutosh Bapat writes: > On Sun, Feb 18, 2024 at 1:59 PM Andy Fan wrote: >> >> >> I tried your idea with the attatchment, it is still in a drafted state >> but it can be used as a prove-of-concept and for better following >> communicating. Just one point

Re: Shared detoast Datum proposal

Hi, I didn't another round of self-review. Comments, variable names, the order of function definition are improved so that it can be read as smooth as possible. so v6 attached. -- Best Regards Andy Fan >From f2e7772228e8a18027b9c29f10caba9c6570d934 Mon Sep 17 00:00:00 2001 From: &q

Re: Shared detoast Datum proposal

eck at all. If we avoid the createplan/setref.c changes, probabaly some unrelated StepOp needs the extra check as well? When I worked with the UniqueKey feature, I maintained a UniqueKey.README to summaried all the dicussed topics in threads, the README is designed to save the effort for more reviewer, I think I

Re: Reduce useless changes before reassembly during logical replication

invalid entry*. if the caller has built it already, like the existing cases in master, nothing will happen except a simple transaction state check. Then in the FilterByTable case we just leave it for get_rel_sync_sync_entry. See the attachemnt for the idea. -- Best Regards Andy Fan >From 90b8df3

Re: Shared detoast Datum proposal

I see your reply when I started to write a more high level document. Thanks for the step by step help! Tomas Vondra writes: > On 2/20/24 19:38, Andy Fan wrote: >> >> ... >> >>> I think it should be done the other >>> way around, i.e. the patch

Re: Reduce useless changes before reassembly during logical replication

is spilled to disk, but the CPU cost for Reorder should be still paid I think. [1] https://www.postgresql.org/message-id/87o7cadqj3.fsf%40163.com -- Best Regards Andy Fan >From 90b8df330df049bd1d7e881dc6e9b108c17b0924 Mon Sep 17 00:00:00 2001 From: "yizhi.fzh" Date: Wed, 21 Feb 2

Re: Shared detoast Datum proposal

st both master and patched versions, the memory usage looks stable. In progress work: I'm still running tpc-h scale 100 to see if anything interesting finding, that is in progress. As for the scale 10: master: 55s patched: 56s The reason is q9 plan changed a bit, the real reason needs some mor

Re: Shared detoast Datum proposal

oth way has its user case, kind of heap store and columna store. FWIW, as I shown in the test case, this feature is not only helpful for big datum, it is also helpful for small toast datum. -- Best Regards Andy Fan

Re: Shared detoast Datum proposal

> On 2/26/24 14:22, Andy Fan wrote: >> >>... >> >>> Also, toasted values >>> are not always being used immediately and as a whole, i.e. jsonb values are >>> fully >>> detoasted (we're working on this right now) to extract the s

Re: Shared detoast Datum proposal

ve some different issues than the current patch. Just I have many implemetion questions in my mind. > Andy, thank you! I'll check the last patch set out and reply in a day > or two. Thank you for your attention! -- Best Regards Andy Fan

Re: Better error messages for %TYPE and %ROWTYPE in plpgsql

d by me at the first and resolve it by adding a odd parameter. Then the odd parameter blocked the whole process. [1] https://www.postgresql.org/message-id/87r0hmvuvr....@163.com -- Best Regards Andy Fan

Re: Better error messages for %TYPE and %ROWTYPE in plpgsql

"David G. Johnston" writes: > On Mon, Feb 26, 2024 at 5:46 PM Andy Fan wrote: > > > Per recent discussion[1], plpgsql returns fairly unhelpful "syntax > > error" messages when a %TYPE or %ROWTYPE construct references a > > nonexistent object.

Re: Shared detoast Datum proposal

gresql.org/message-id/875xyb1a6q.fsf%40163.com -- Best Regards Andy Fan

Re: Shared detoast Datum proposal

g, I added the alternative design part for the idea of TOAST cache. -- Best Regards Andy Fan >From 66c64c197a5dab97a563be5a291127e4c5d6841d Mon Sep 17 00:00:00 2001 From: "yizhi.fzh" Date: Sun, 3 Mar 2024 13:48:25 +0800 Subject: [PATCH v9 1/1] shared detoast datum See the overall

a wrong index choose when statistics is out of date

ing 9:00 to 18:00 and there are 2 rows per seconds for other time range. For now, I think option 1 may be easier to happen. -- Best Regards Andy Fan

Re: Shared detoast Datum proposal

Tomas Vondra writes: > On 3/3/24 02:52, Andy Fan wrote: >> >> Hi Nikita, >> >>> >>> Have you considered another one - to alter pg_detoast_datum >>> (actually, it would be detoast_attr function) and save >>> detoasted datums

Re: Shared detoast Datum proposal

Tomas Vondra writes: > On 2/26/24 16:29, Andy Fan wrote: >> >> ...> >> I can understand the benefits of the TOAST cache, but the following >> issues looks not good to me IIUC: >> >> 1). we can't put the result to tts_values[*] since without the

Re: Shared detoast Datum proposal

Tomas Vondra writes: > On 3/3/24 07:10, Andy Fan wrote: >> >> Hi, >> >> Here is a updated version, the main changes are: >> >> 1. an shared_detoast_datum.org file which shows the latest desgin and >> pending items during discussion. >> 2.

Re: a wrong index choose when statistics is out of date

David Rowley writes: > On Sun, 3 Mar 2024 at 20:08, Andy Fan wrote: >> The issue can be reproduced with the following steps: >> >> create table x_events (.., created_at timestamp, a int, b int); >> >> create index idx_1 on t(created_at, a); >>

Re: a wrong index choose when statistics is out of date

Andrei Lepikhov writes: > On 3/3/2024 14:01, Andy Fan wrote: >> 1. We can let the user define the column as the value is increased day by >> day. the syntax may be: >> ALTER TABLE x_events ALTER COLUMN created_at ALWAYS_INCREASED. >> then when a query lik

Re: Eager aggregation, take 3

irst and hope we can really progress on this topic. Good luck! -- Best Regards Andy Fan

Re: Shared detoast Datum proposal

e context is > passed as an argument, unless absolutely necessary. Hmm, in this case, if we don't add the new argument, we have to get the detoast datum in Context-1 and copy it to the desired memory context, which is the thing I want to avoid. I think we have a same decision to make on the TOAST cache method as well. -- Best Regards Andy Fan

Re: Extract numeric filed in JSONB more effectively

Peter Eisentraut writes: > On 09.02.24 10:05, Andy Fan wrote: >> 2. Where is the current feature blocked for the past few months? >> It's error message compatible issue! Continue with above setup: >> master: >> select * from tb where (a->'b')::numer

Re: Shared detoast Datum proposal

In any case, my concern is more about having to do this when creating > the plan at all, the code complexity etc. Not just because it might have > performance impact. I think the main trade-off is TOAST cache method is pretty non-invasive but can't control the eviction well, the impacts includes: 1. may evicting the datum we want and kept the datum we don't need. 2. more likely to use up all the memory which is allowed. for example: if we set the limit to 1MB, then we kept more data which will be not used and then consuming all of the 1MB. My method is resolving this with some helps from other modules (kind of invasive) but can control the eviction well and use the memory as less as possible. -- Best Regards Andy Fan

Re: Shared detoast Datum proposal

imit is hit. This would make a noticable difference when we want to set a high limit and we have some high active sessions, like 100 * 40MB = 4GB. > On 3/4/24 18:08, Andy Fan wrote: >> ... >>> >>>> I assumed that releasing all of the memory at the end of executor once

Re: remaining sql/json patches

he case, the method in [1] can avoid the user to modify these queries for the using the new function. [1] https://www.postgresql.org/message-id/8734t6c5rh@163.com -- Best Regards Andy Fan

Re: a wrong index choose when statistics is out of date

David Rowley writes: > On Tue, 5 Mar 2024 at 00:37, Andy Fan wrote: >> >> David Rowley writes: >> > I don't think it would be right to fudge the costs in any way, but I >> > think the risk factor for IndexPaths could take into account the >> >

Re: a wrong index choose when statistics is out of date

Any feedback is welcome. -- Best Regards Andy Fan >From f8cca472479c50ba73479ec387882db43d203522 Mon Sep 17 00:00:00 2001 From: "yizhi.fzh" Date: Tue, 5 Mar 2024 18:27:48 +0800 Subject: [PATCH v0 1/1] Add a "force_generic" attoptions for selfunc.c Sometime user just ca

Re: a wrong index choose when statistics is out of date

David Rowley writes: > On Wed, 6 Mar 2024 at 02:09, Andy Fan wrote: >> This patch introduces a new attoptions like this: >> >> ALTER TABLE t ALTER COLUMN col set (force_generic=true); >> >> Then selfunc.c realizes this and ignore the special

Re: a wrong index choose when statistics is out of date

Andrei Lepikhov writes: > On 5/3/2024 19:56, Andy Fan wrote: >> I think it is OK for a design review, for the implementaion side, the >> known issue includes: >> 1. Support grap such infromation from its parent for partitioned table >> if the child doesn't have

Re: a wrong index choose when statistics is out of date

David Rowley writes: > On Thu, 7 Mar 2024 at 23:40, Andy Fan wrote: >> >> David Rowley writes: >> > If you don't want the planner to use the statistics for the column why >> > not just do the following? >> >> Acutally I didn't want the

Re: a wrong index choose when statistics is out of date

imizer statistics cause the rows in outer relation to be 1, which make the Nest loop is choosed. I'm not sure your idea could help on this or can help on this than mine at this aspect. -- Best Regards Andy Fan

Re: remaining sql/json patches

jian he writes: > On Tue, Mar 5, 2024 at 12:38 PM Andy Fan wrote: >> >> >> In the commit message of 0001, we have: >> >> """ >> Both JSON_VALUE() and JSON_QUERY() functions have options for >> handling EMPTY and ERROR conditions, whi

Re: Extract numeric filed in JSONB more effectively

me more generic purpose which has to pay some extra effort, and even if we have some chance to improve JSON_VALUE, I don't think it shoud not block the patch here (I'd like to learn more about this, it may takes some time!) So I think the my patch here can be go ahead again, what do you think? [1] https://www.postgresql.org/message-id/CACJufxGtetrn34Hwnb9D2if5D_HOPAh235MtEZ1meVYx-BiNtg%40mail.gmail.com -- Best Regards Andy Fan

Re: a wrong index choose when statistics is out of date

1e2-8629-734e3c8ba613%40postgrespro.ru -- Best Regards Andy Fan

Re: A new strategy for pull-up correlated ANY_SUBLINK

> Yes, it is true! I prefer to believe this deserves a separate patch. Any feedback is welcome! -- Best Regards Andy Fan From 3e2c8b46928a7f246ee7066b9ad160cf18a2e952 Mon Sep 17 00:00:00 2001 From: Andy Fan Date: Wed, 5 Apr 2023 14:45:11 +0800 Subject: [PATCH v3] Pull up direct-correlat

Fix the miss consideration of tuple_fraction during add_paths_to_append_rel

lect * from tenk1 order by hundred) union all (select * from tenk2 order by hundred) limit 3; Without the patch: Execution Time: 7.856 ms with the patch: Execution Time: 0.224 ms Any suggestion is welcome. [1] https://www.postgresql.org/message-id/11228.1118365833%40sss.pgh.pa.us -- Best

Re: Can we rely on the ordering of paths in pathlist?

Path *get_cheapest_parallel_safe_total_inner(List *paths) to Path *get_cheapest_parallel_safe_total_inner(RelOptInfo *rel); and scan the rel->pathlist in the function body. -- Best Regards Andy Fan

Re: Fix the miss consideration of tuple_fraction during add_paths_to_append_rel

on in partial_pathlist for parallel > append? > > Thanks for the suggestion, the v2 has fixed the indent issue and I did something about parallel append. Besides that, I restrict the changes happens under bms_equal(rel->relids, root->all_query_rels), which may make this patch safer.

Re: Fix incorrect start up costs for WindowAgg paths (bug #17862)

count(*) over() from tenk1 limit 1; count --- 1 --> We need to scan all the tuples. Should we just return clamp_row_est(partition_tuples)? -- Best Regards Andy Fan

Re: Fix incorrect start up costs for WindowAgg paths (bug #17862)

On Thu, Apr 13, 2023 at 6:09 AM David Rowley wrote: > .On Thu, 13 Apr 2023 at 02:28, Andy Fan wrote: > > The concept of startup_tuples for a WindowAgg looks good to me, but I > > can't follow up with the below line: > > > > + return clamp_row_est(par

Re: Window Function "Run Conditions"

atch. I probably can finish it very soon. But if you are willing to commit it sooner, I am totally fine with it. -- Best Regards Andy Fan

Re: Window Function "Run Conditions"

the patch, it is a good material to study the knowledge in this area. -- Best Regards Andy Fan v1-0003-Try-to-remove-enum-WindowAggStatus.patch Description: Binary data v1-0001-When-we-are-in-PASSTHROUGH-mode-all-the-following.patch Description: Binary data v1-0002-not-return-run-condition-false-tuple-to-upper-nod.patch Description: Binary data

Re: Window Function "Run Conditions"

> > The root cause is even ExecQual(winstate->runcondition, econtext) return > false, we > still return the slot to the upper node. A simple hack can avoid it. > Forget to say 0002 shows what I mean. -- Best Regards Andy Fan

Re: Window Function "Run Conditions"

On Tue, Apr 5, 2022 at 7:49 PM David Rowley wrote: > On Tue, 5 Apr 2022 at 19:38, Andy Fan wrote: > > 1. We can do more on PASSTHROUGH, we just bypass the window function > > currently, but IIUC we can ignore all of the following tuples in > current partition > > o

A fastpath for TransactionIdIsCurrentTransactionId

- if (!TransactionIdIsNormal(xid)) + + if (TransactionIdPrecedes(xid, TransactionXmin)) return false; if (TransactionIdEquals(xid, GetTopTransactionIdIfAny())) -- Best Regards Andy Fan

Re: How to generate a WAL record spanning multiple WAL files?

e very large? like 64MB. XLogBeginInsert(); XLogRegisterData((char *)&xl_append, sizeof(xl_cstore_append)); XLogRegisterData((char *)data, len); XLogInsert(..); -- Best Regards Andy Fan

Re: How to generate a WAL record spanning multiple WAL files?

On Wed, Apr 6, 2022 at 12:41 AM Robert Haas wrote: > On Tue, Apr 5, 2022 at 10:10 AM Andy Fan wrote: > >> > I wanted to have a WAL record spanning multiple WAL files of size, say > >> > 16MB. I'm wondering if the Full Page Images (FPIs) of a TOAST table >

Re: Avoid detoast overhead when possible

gt.fsf%40163.com -- Best Regards Andy Fan

Is a clearer memory lifespan for outerTuple and innerTuple useful?

ntext inner_tuple_memory; } JoinState; /* @@ -2064,8 +2066,6 @@ typedef struct MergeJoinState TupleTableSlot *mj_MarkedTupleSlot; TupleTableSlot *mj_NullOuterTupleSlot; TupleTableSlot *mj_NullInnerTupleSlot; - ExprContext *mj_OuterEContext; - ExprContext *mj_InnerEContext; } MergeJoinState; /* -- 2.34.1 -- Best Regards Andy Fan

Re: Is a clearer memory lifespan for outerTuple and innerTuple useful?

Andy Fan writes: > ..., I attached the 2 MemoryContext in > JoinState rather than MergeJoinState, which is for the "shared detoast > value"[0] more or less. > After thinking more, if it is designed for "shared detoast value" patch (happens on ExecInterpExp

Re: Is a clearer memory lifespan for outerTuple and innerTuple useful?

Andy Fan writes: > Andy Fan writes: > >> ..., I attached the 2 MemoryContext in >> JoinState rather than MergeJoinState, which is for the "shared detoast >> value"[0] more or less. >> In order to delimit the scope of this discussion, I attached the

Re: Is a clearer memory lifespan for outerTuple and innerTuple useful?

ee' to free the detoast values and but a dedicated memory context pays more costs on the setup, but a more efficient MemoryContextReset. > > On Sun, Dec 17, 2023 at 4:52 PM Andy Fan wrote: > > Andy Fan writes: > > > Andy Fan writes: > > > >> ..., I attache

Shared detoast Datum proposal

e. 2. JIT is not adapted for this purpose yet. 3. This feature builds a strong relationship between slot->tts_values and slot->pre_detoast_attrs. for example slot->tts_values[1] holds a detoast datum, so 1 is in the slot->pre_detoast_attrs bitmapset, however if someone changes

Re: Removing const-false IS NULL quals and redundant IS NOT NULL quals

se-relation-and-used-it-for-mark-d.patch -- Best Regards Andy Fan

Re: Removing const-false IS NULL quals and redundant IS NOT NULL quals

is in our current infrastructure, I still raise this up in case I missed anything. -- Best Regards Andy Fan

Re: Shared detoast Datum proposal

Andy Fan writes: > > Some Known issues: > -- > > 1. Currently only Scan & Join nodes are considered for this feature. > 2. JIT is not adapted for this purpose yet. JIT is adapted for this feature in v2. Any feedback is welcome. -- Best R

the s_lock_stuck on perform_spin_delay

l.com [2] https://www.postgresql.org/message-id/attachment/123659/v5-0001-WIP-Track-relation-sizes-in-shared-memory.patch -- Best Regards Andy Fan >From 7d7fd0f0e9b13a290bfffaec0ad40773191155f2 Mon Sep 17 00:00:00 2001 From: "yizhi.fzh" Date: Thu, 4 Jan 2024 14:33:37 +0800 Subje

Re: the s_lock_stuck on perform_spin_delay

Hi Matthias and Robert, Matthias van de Meent writes: > On Thu, 4 Jan 2024 at 08:09, Andy Fan wrote: >> >> My question is if someone doesn't obey the rule by mistake (everyone >> can make mistake), shall we PANIC on a production environment? IMO I >> think it

Re: the s_lock_stuck on perform_spin_delay

Hi, Andres Freund writes: > > On 2024-01-04 14:59:06 +0800, Andy Fan wrote: >> My question is if someone doesn't obey the rule by mistake (everyone >> can make mistake), shall we PANIC on a production environment? IMO I >> think it can be a WARNING on a producti

Re: Shared detoast Datum proposal

Hi, vignesh C writes: > On Mon, 1 Jan 2024 at 19:26, Andy Fan wrote: >> >> >> Andy Fan writes: >> >> > >> > Some Known issues: >> > -- >> > >> > 1. Currently only Scan & Join nodes are considered for

Re: the s_lock_stuck on perform_spin_delay

when run 'make check-world'. > - make sure that interrupts can't trigger the stuck lock much quicker, which > afaict can happen today I can't follow this, do you mind explain more about this a bit? -- Best Regards Andy Fan >From 80cf987d1abe2cdae195bd5eea520e2814

Re: Extract numeric filed in JSONB more effectively

been configured to capture this during commit. After we reach an agreement about the 'catversion.h' stuff, the next version of patch should fix this issue. -- Best Regards Andy Fan

Re: the s_lock_stuck on perform_spin_delay

CK_FOR_INTERRUPTS(); LWLockRelease(); Even we got ERROR/FATAL in the CHECK_FOR_INTERRUPTS, I think the LWLock are suppose to be released because of the above statement. Am I missing anything? -- Best Regards Andy Fan

Re: Shared detoast Datum proposal

Andy Fan writes: >> >> One of the tests was aborted at CFBOT [1] with: >> [09:47:00.735] dumping /tmp/cores/postgres-11-28182.core for >> /tmp/cirrus-ci-build/build/tmp_install//usr/local/pgsql/bin/postgres >> [09:47:01.035] [New LWP 28182] > > There wa

Re: the s_lock_stuck on perform_spin_delay

Hi, Robert Haas writes: > On Sun, Jan 7, 2024 at 9:52 PM Andy Fan wrote: >> > I think we should add cassert-only infrastructure tracking whether we >> > currently hold spinlocks, are in a signal handler and perhaps a few other >> > states. That

Re: the s_lock_stuck on perform_spin_delay

Hi, Robert Haas writes: > On Mon, Jan 8, 2024 at 9:40 PM Andy Fan wrote: >> The singler handler I was refering to is 'CHECK_FOR_INTERRUPTS', Based >> on this, spin_lock and lwlock are acted pretty differently. > > CHECK_FOR_INTERRUPTS() is not a signal handle

Re: Extract numeric filed in JSONB more effectively

(Sorry for leaving this discussion for such a long time, how times fly!) On Sun, Aug 27, 2023 at 6:28 AM Chapman Flack wrote: > On 2023-08-22 08:16, Chapman Flack wrote: > > On 2023-08-22 01:54, Andy Fan wrote: > >> After we label it, we will get error like this: >

Re: Extract numeric filed in JSONB more effectively

ion. I tried the jsonb_xx_start and jsonb_finish_numeric style, and it looks like a good experience and it may not make things too complicated even if the above things happen IMO. Any feedback is welcome. -- Best Regards Andy Fan v11-0001-optimize-casting-jsonb-to-a-given-type.patch Description: Binary data

Re: Extract numeric filed in JSONB more effectively

actor, we have to implement two DirectFunctionCall1. Point b) is the key reason I am not willing to do it. Or do I miss other important reasons? -- Best Regards Andy Fan v12-0001-optimize-casting-jsonb-to-a-given-type.patch Description: Binary data

Re: Extract numeric filed in JSONB more effectively

root, VARDATA_ANY(key),\ VARSIZE_ANY_EXHDR(key), NULL); I will send an updated version soon. -- Best Regards Andy Fan

Re: Extract numeric filed in JSONB more effectively

Hi, v13 attached. Changes includes: 1. fix the bug Jian provides. 2. reduce more code duplication without DirectFunctionCall. 3. add the overlooked jsonb_path_query and jsonb_path_query_first as candidates -- Best Regards Andy Fan v13-0001-optimize-casting-jsonb-to-a-given-type.patch

Re: A minor adjustment to get_cheapest_path_for_pathkeys

n mental stress, they can pick this and commit this. Actually I also want to know what "Ready for Committer" is designed for, and when/who can mark a patch as "Ready for Committer" ? -- Best Regards Andy Fan

Re: A minor adjustment to get_cheapest_path_for_pathkeys

On Wed, Sep 6, 2023 at 2:45 PM Andy Fan wrote:uld have a different conversation... > > I like this consultation, so +1 from me :) > s/consultation/conclusion. -- Best Regards Andy Fan

Re: Extract numeric filed in JSONB more effectively

RNALOID, 0, >InvalidOid, >COERCE_IMPLICIT_CAST); > > if no need, output typmod (usually -1), so here should be -1 rather than 0? I agree. -1 is better than 0. Thanks for the code level review again! I want to wait for some longer time to gather more feedback. I'm willing to name it better, but hope I didn't rename it to A and rename it back shortly. -- Best Regards Andy Fan

Re: A minor adjustment to get_cheapest_path_for_pathkeys

e past contribution of the author should be a factor as well. Like Richard has provided lots of performance improvement, bug fix, code reviews, so I believe more attention from committers should be a reasonable request. -- Best Regards Andy Fan

make add_paths_to_append_rel aware of startup cost

also added some test cases for code coverage purposes. Any feedback is welcome! [1] https://www.postgresql.org/message-id/flat/CAKU4AWqEnzhUTxopVhENC3vs6NnYV32+e6GSBtp1rAv0ZNX=m...@mail.gmail.com -- Best Regards Andy Fan v1-0001-make-add_paths_to_append_rel-aware-of-startup-cos.patch Description: Binary data

Re: A minor adjustment to get_cheapest_path_for_pathkeys

On Wed, Sep 6, 2023 at 8:50 PM Robert Haas wrote: > On Wed, Sep 6, 2023 at 2:45 AM Andy Fan wrote: > > I guess the *valuable* sometimes means the effort we pay is greater > > than the benefit we get, As for this patch, the benefit is not huge (it > > is possible the compi

Re: MergeJoin beats HashJoin in the case of multiple hash clauses

virtualbuckets; innerbucketsize is a fraction of rows in all the rows, so it is between 0.0 and 1.0. and virtualbuckets is the number of buckets in total (when considered the mutli batchs), how is it possible for 'innerbucketsize > virtualbuckets' ? Am I missing something? -- Best Regards Andy Fan

Re: make add_paths_to_append_rel aware of startup cost

thod-b directly and modify set_subquery_pathlist to do the same for consistency. -- Best Regards Andy Fan

Re: Redundant Unique plan node for table with a unique index

varnullingrels so I will start working on UniqueKey stuff very soon, thank you David for remember of this feature! -- Best Regards Andy Fan

Re: Extract numeric filed in JSONB more effectively

On Thu, Sep 14, 2023 at 5:18 AM Chapman Flack wrote: > On 2023-09-04 10:35, Andy Fan wrote: > > v13 attached. Changes includes: > > > > 1. fix the bug Jian provides. > > 2. reduce more code duplication without DirectFunctionCall. > > 3. add the

Is it possible to change wal_level online

y it would be the key blocker for this. Basically I agree that changing the wal_level online will be a good experience for users. -- Best Regards Andy Fan

Re: Buffer ReadMe Confuse

one and the same buffer page. > > You are right that different transactions can pin the same buffer, but that does not conflict with what the README says, which is talking about once the transaction is completed, all the Pins are removed. -- Best Regards Andy Fan

Re: Is it possible to change wal_level online

On Thu, Sep 14, 2023 at 9:22 PM Euler Taveira wrote: > On Thu, Sep 14, 2023, at 7:05 AM, Andy Fan wrote: > > Currently it is complained that wal_level changes require an instance > restart, I'm not familiar with this stuff so far and I didn't get any good > information

Re: Support prepared statement invalidation when result types change

7;t go through any of the drivers in detail, but I hope my concern is expressed correctly. -- Best Regards Andy Fan

Re: Extract numeric filed in JSONB more effectively

hallow copy is removed as well. Things are not addressed yet: 1. the error message handling. 2. if we have chances to optimize _tz functions, I guess no. 3. function naming issue. I think I can get it modified once after all the other issues are addressed. -- Best Regards Andy Fan v14-0002

Re: make add_paths_to_append_rel aware of startup cost

Hi David, Thanks for taking a look at this! On Fri, Sep 15, 2023 at 3:15 PM David Rowley wrote: > On Thu, 7 Sept 2023 at 04:37, Andy Fan wrote: > > Currently add_paths_to_append_rel overlooked the startup cost for > creating > > append path, so it may have lost some op

Re: make add_paths_to_append_rel aware of startup cost

On Mon, Sep 18, 2023 at 11:58 AM David Rowley wrote: > On Mon, 18 Sept 2023 at 01:42, Andy Fan wrote: > > On Fri, Sep 15, 2023 at 3:15 PM David Rowley > wrote: > >> Instead of doing that, why don't you just create a completely new > >> AppendPath containing

Re: make add_paths_to_append_rel aware of startup cost

; subquery and so on, If we have more tables to join, we use > cheapest startup cost.". This is what is in my mind now. > > Here is an updated version to show what's in my mind. -- Best Regards Andy Fan v3-0001-make-add_paths_to_append_rel-aware-of-startup_cos.patch Description: Binary data

Re: Questioning an errcode and message in jsonb.c

e, I'd be pretty willing to see what some more experienced people say about this. I think just documenting the impatible behavior is an option as well. -- Best Regards Andy Fan

Re: Questioning an errcode and message in jsonb.c

error message is a bit confusing to me, it would be good to see the proposal code as well. The only concern from me is that the new error from newer version is not compatible with the older versions, which may matters matters or doesn't match, I don't know. [0] https://www.postgresql.org/message-id/43a988594ac91a63dc4bb49a94303a42%40anastigmatix.net -- Best Regards Andy Fan

Re: Report planning memory in EXPLAIN ANALYZE

things. Personally I am pretty like patch 1, we just need to refactor some words to make everything clearer. -- Best Regards Andy Fan

<    1   2   3   4   5   6   7   >