Re: Questioning an errcode and message in jsonb.c

r doesn't match, I don't know. > > Do you mind providing the patch in your mind, and let's just ignore the compatible issue for now. I think that would be pretty helpful for further discussion. -- Best Regards Andy Fan

Re: Report planning memory in EXPLAIN ANALYZE

Hi Ashutosh, On Fri, Sep 22, 2023 at 5:56 PM Ashutosh Bapat wrote: > Hi Andy, > Thanks for your feedback. > > On Fri, Sep 22, 2023 at 8:22 AM Andy Fan wrote: > > > > 1). The commit message of patch 1 just says how it does but doesn't > > say why it does. Afte

Re: make add_paths_to_append_rel aware of startup cost

e of cheapest fractional cost but no gain so far:( -- Best Regards Andy Fan

Re: make add_paths_to_append_rel aware of startup cost

On Wed, Oct 4, 2023 at 8:41 AM David Rowley wrote: > On Sun, 1 Oct 2023 at 21:26, Andy Fan wrote: > >> But overall, I'm more inclined to just go with the more simple "add a > >> cheap unordered startup append path if considering cheap startup > >> plan

Re: Extract numeric filed in JSONB more effectively

the commit message. 3. function naming issue. I think I can get it modified once after > all the other issues are addressed. > > [1] https://www.postgresql.org/message-id/d70280648894e56f9f0d12c75090c3d8%40anastigmatix.net -- Best Regards Andy Fan

Re: Draft LIMIT pushdown to Append and MergeAppend patch

is better to provide an example to show how much benefits we can get. As for this case, I'm doubtful it can work as an improvement. 2. Enable LIMIT pushdown for FDW partitions. > The same as above, some testing is helpful. -- Best Regards Andy Fan

Re: Draft LIMIT pushdown to Append and MergeAppend patch

On Mon, Oct 9, 2023 at 8:52 AM David Rowley wrote: > On Sun, 8 Oct 2023 at 18:32, Michał Kłeczek wrote: > > On 8 Oct 2023, at 03:33, Andy Fan wrote: > >> For the patches for performance improvement, it is better to provide > >> an example to show how much benefi

Re: Crash in add_paths_to_append_rel

gt;param_info without first checking that we have a > > valid cheapest_startup_path. > > I pushed this with just minor adjustments to the comments you wrote. I > didn't feel the need to reiterate on the set_cheapest() comments. > > Thanks Richard for the report and also

Re: A new strategy for pull-up correlated ANY_SUBLINK

d, it became possible after replacing the "in" operator with > "=". > I didn't notice much difference between the 'in' and '=', maybe I missed something? > I took the liberty of adding this to your patch and added myself as > reviewer, if you don't mind. > Sure, the patch after your modification looks better than the original. I'm not sure how the test case around "because of got one row" is relevant to the current changes. After we reach to some agreement on the above discussion, I think v4 is good for committer to review! -- Best Regards Andy Fan

Re: A new strategy for pull-up correlated ANY_SUBLINK

. After we reach to some agreement > on the above discussion, I think v4 is good for committer to review! > > > Thank you!) I am ready to discuss it. > Actually I meant to discuss the "Unfortunately, I found a request..", looks we have reached an agreement there:) -- Best Regards Andy Fan

Re: A new strategy for pull-up correlated ANY_SUBLINK

Hi Tom, Would you like to have a look at this? The change is not big and the optimization has also been asked for many times. The attached is the v5 version and I also try my best to write a good commit message. Here is the commit fest entry: https://commitfest.postgresql.org/45/4268/ v5-000

Re: [PATCH] Erase the distinctClause if the result is unique by definition

se of unique keys rather than how it looks at unique > indexes and group by / distinct clauses. > > I can do this after we have agreement on the UniquePath. For my cbbot failure, another strange thing is "A" appear ahead of "a" after the order by.. Still didn't find out why. [1] https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.83298 Regards Andy Fan

Re: [PATCH] Erase the distinctClause if the result is unique by definition

find this in your patch or in the code. > > This is a proposal from David, so not in current patch/code :) Regards Andy Fan

Re: Index Skip Scan

> > > I think the UniqueKeys may need to be changed from using > EquivalenceClasses to use Exprs instead. > When I try to understand why UniqueKeys needs EquivalenceClasses, see your comments here. I feel that FuncExpr can't be used to as a UniquePath even we can create unique index on f(a) and

Re: [PATCH] Erase the distinctClause if the result is unique by definition

On Wed, Mar 11, 2020 at 6:49 AM David Rowley wrote: > On Wed, 11 Mar 2020 at 02:50, Ashutosh Bapat > wrote: > > > > On Tue, Mar 10, 2020 at 1:49 PM Andy Fan > wrote: > > > In my current implementation, it calculates the uniqueness for each > > > BaseRel o

Re: Index Skip Scan

On Tue, Mar 10, 2020 at 4:32 AM James Coleman wrote: > On Mon, Mar 9, 2020 at 3:56 PM Dmitry Dolgov <9erthali...@gmail.com> > wrote: > > > > Assuming we'll implement it in a way that we do not know about what kind > > of path type is that in create_distinct_path, then it can also work for > > Pro

Re: [PATCH] Erase the distinctClause if the result is unique by definition

Hi David: On Thu, Mar 12, 2020 at 3:51 PM David Rowley wrote: > On Wed, 11 Mar 2020 at 17:23, Andy Fan wrote: > > Now I am convinced that we should maintain UniquePath on RelOptInfo, > > I would see how to work with "Index Skip Scan" patch. > > I've attached

Re: [PATCH] Erase the distinctClause if the result is unique by definition

On Fri, Mar 13, 2020 at 11:46 AM David Rowley wrote: > On Fri, 13 Mar 2020 at 14:47, Andy Fan wrote: > > 1. for pupulate_baserel_uniquekeys, we need handle the "pk = Const" > as well. > > (relation_has_unqiue_for has a similar logic) currently the follow

Re: [PATCH] Erase the distinctClause if the result is unique by definition

ther than hash. The strategy sounds awesome, but I didn't check the details so far. 5. more clearer commit message. 6. any more ? Any feedback is welcome, Thanks for you for your any ideas, suggestions, demo code! Best Regards Andy Fan v4-0001-Patch-Bypass-distinctClause-groupbyClause

Re: [PATCH] Erase the distinctClause if the result is unique by definition

Hi David: Thanks for your time. On Wed, Mar 18, 2020 at 9:56 AM David Rowley wrote: > On Mon, 16 Mar 2020 at 06:01, Andy Fan wrote: > > > > Hi All: > > > > I have re-implemented the patch based on David's suggestion/code, Looks > it > > works

Re: [PATCH] Erase the distinctClause if the result is unique by definition

Hi David: On Wed, Mar 18, 2020 at 12:13 PM David Rowley wrote: > On Wed, 18 Mar 2020 at 15:57, Andy Fan wrote: > > I'm now writing the code for partition index stuff, which > > is a bit of boring, since every partition may have different unique > index. > >

[PATCH] Keeps tracking the uniqueness with UniqueKey

g/message-id/flat/CAKU4AWqOORqW900O-%2BL4L2%2B0xknsEqpfcs9FF7SeiO9TmpeZOg%40mail.gmail.com#f5d97cc66b9cd330add2fbb004a4d107 [2] https://www.postgresql.org/message-id/CAKU4AWqOORqW900O-%2BL4L2%2B0xknsEqpfcs9FF7SeiO9TmpeZOg%40mail.gmail.com Best regards Andy Fan v1-0001-Maintain-the-uniqueness-of-a-Query-from-bottom-to.patch Description: Binary data

Re: Index Skip Scan

> > > On Mon, Mar 23, 2020 at 1:55 AM Floris Van Nee > wrote: > > I'm unsure which version number to give this patch (to continue with > numbers from previous skip scan patches, or to start numbering from scratch > again). It's a rather big change, so one could argue it's mostly a separate > patch

Re: Index Skip Scan

On Wed, Mar 25, 2020 at 12:41 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Wed, Mar 11, 2020 at 06:56:09PM +0800, Andy Fan wrote: > > > > There was a dedicated thread [1] where David explain his idea very > > detailed, and you can also check that me

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Mon, Mar 23, 2020 at 6:21 PM Andy Fan wrote: > Greetings. > > This thread is a follow-up thread for [1], where I submit a patch for > erasing the > distinct node if we have known the data is unique for sure. But since the > implementation has changed a lot from the beginnin

Re: [PATCH] Erase the distinctClause if the result is unique by definition

I have started the new thread [1] to continue talking about this. Mr. cfbot is happy now. [1] https://www.postgresql.org/message-id/flat/CAKU4AWrwZMAL%3DuaFUDMf4WGOVkEL3ONbatqju9nSXTUucpp_pw%40mail.gmail.com Thanks >

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Because I replied the old thread, cfbot run a test based on the old patch on that thread. I have detached the old thread from commitfest. Reply this email again to wake up Mr. cfbot with the right information. v2-0001-Maintain-the-uniqueness-of-a-Query-from-bottom-to.patch Description: Binary

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

r in comments. 3. Renamed the field "grantee" as "guarantee". Best Regards Andy Fan v3-0001-Maintain-UniqueKey-at-each-RelOptInfo-this-inform.patch Description: Binary data

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

Thanks David for your time, I will acknowledge every item you mentioned with the updated patch. Now I just talk about part of them. > 1. There seem to be some cases where joins are no longer being > detected as unique. This is evident in postgres_fdw.out. We shouldn't > be regressing any of the

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

The updated patch should fixed all the issues. See the comments below for more information. On Tue, Mar 31, 2020 at 9:44 AM David Rowley wrote: > On Sun, 29 Mar 2020 at 20:50, Andy Fan wrote: > > Some other changes made in the new patch: > > 1. Fixed bug for UniqueKey calcul

Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

ve mistakenly supposed in some past discussions.) > > Agreed for remove_useless_groupby_columns(), but we'd need it if we > wanted to detect functional dependencies in > check_functional_grouping() using unique indexes. > Thanks for the explanation. I will add the removal in the next version of this patch. Best Regards Andy Fan

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

p; create index on q(a); select * from p, q where p.a = q.a and p.a in (3, 20); Run the above query in both prepared and no prepared case, I get the following results: | workload | with this feature | w/o this feature | |--+---+--| | Prepared

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

ecb23b5e7884cc34d71301 Author: David Rowley Date: Tue Feb 1 20:56:40 2022 +0800 Introudce ec_filters in EquivalenceClass struct, the semantics is the quals can be applied to any EquivalenceMember in this EC. Later this information is used to generate new RestrictInfo and was distr

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

n now. [1] https://www.postgresql.org/message-id/CAKU4AWpo9z0hMHDWUKuce4Z-NpcybV0J2UVu5%2BDVwyP-CrHCQg%40mail.gmail.com -- Best Regards Andy Fan

Re: Use generation context to speed up tuplesorts

estimation to allocate initial memory and GenerationContext improves like 0003/0004. Would this work? -- Best Regards Andy Fan

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

> smarter than we are now, which is, in a nutshell, as dumb as possible. +1. I asked custom to add the derivable quals manually for 10+ of table each query last year and gained great results. Anyone still have interest in this? Or is a better solution really possible? Or is the current method too bad to rescue? -- Best Regards Andy Fan

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

On Fri, Feb 18, 2022 at 4:15 AM Robert Haas wrote: > On Tue, Feb 1, 2022 at 10:08 AM Andy Fan wrote: > > To address the row estimation issue, The most straightforward way to fix > this is to > > ignore the derived clauses when figuring out the RelOptInfo->rows on > ba

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

ost an update patch at that time. -- Best Regards Andy Fan

Consider parent's stats for set_append_rel_size.

but generally I think it would be OK. Another strategy is we should check if init partition prune can happen. if we are sure about that, we adapt the above way. or else we can use the local stats strategy still. [1] https://www.postgresql.org/message-id/CAExHW5t5Q7JuUW28QMRO7szuHcbsfx4M9

2 questions about volatile attribute of pg_proc.

optimized away.)" I think they are different semantics. One of the results is volatile functions can't be removed by remove_unused_subquery_output even if it doesn't have side effects. for example: select b from (select an_expensive_random(), b from t); Is it by design on purpose

Re: 2 questions about volatile attribute of pg_proc.

o any obvious reason to reject it. -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: 2 questions about volatile attribute of pg_proc.

> > I'm listening to any obvious reason to reject it. > > Any obvious reason to reject it because of it would be a lose battle for sure, so I would not waste time on it. Or vote up if you think it is possible and useful. -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: 2 questions about volatile attribute of pg_proc.

On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule wrote: > > > út 20. 4. 2021 v 4:47 odesílatel Andy Fan > napsal: > >> >> >> > - a PL/PGSQL function's meaning depends on the search path in effect >> when it is called, unless it has a SET search_

Re: 2 questions about volatile attribute of pg_proc.

On Tue, Apr 20, 2021 at 11:32 AM Pavel Stehule wrote: > > > út 20. 4. 2021 v 5:16 odesílatel Andy Fan > napsal: > >> >> >> On Tue, Apr 20, 2021 at 10:57 AM Pavel Stehule >> wrote: >> >>> >>> >>> út 20. 4. 2021 v 4:47 odesí

prerequisites of pull_up_sublinks

outer join's ON clause we can only * do this if the sublink is degenerate (ie, references only the nullable * side of the join). I tried to write some SQLs but still can't understand the above comments. Any help here? -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: prerequisites of pull_up_sublinks

On Wed, Apr 21, 2021 at 4:37 PM David Rowley wrote: > On Wed, 21 Apr 2021 at 14:55, Andy Fan wrote: > > * However, this optimization *only* > > * works at the top level of WHERE or a JOIN/ON clause, because we cannot > > * distinguish whether the ANY ought to return F

Re: Converting NOT IN to anti-joins during planning

are not filtered out > early enough. > > Would this be an issue? Suppose the b.j is NULL when ((a JOIN b) ANTI JOIN c) is evaluated, after the evaluation, the NULL is still there. and can be filtered out later with b.j = d.l; Am I missing something? -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)

, should we consider other methods? 4. Any other suggestion about to resolve the 'duplicated planning case' besides the shared_planner_info method? [1] https://blogs.oracle.com/optimizer/optimizer-transformations:-or-expansion -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

nt, always return 1.0. */ if (rinfo->norm_selec > 1) return (Selectivity) 1.0; -- Best Regards Andy Fan (https://www.aliyun.com/)

Adaptive Plan Sharing for PreparedStmt

above idea should be the one I can think of now. Any thought? Thanks -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

On Wed, May 19, 2021 at 8:15 PM David Rowley wrote: > On Mon, 17 May 2021 at 14:52, Andy Fan wrote: > > Would marking the new added RestrictInfo.norm_selec > 1 be OK? > > There would be cases you'd want to not count the additional clauses in > the selectivity estimatio

How can the Aggregation move to the outer query

he time like SELECT aggfunc(a) FROM t? -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Adaptive Plan Sharing for PreparedStmt

Hi, On Thu, May 20, 2021 at 5:02 PM Tomas Vondra wrote: > Hi, > > On 5/20/21 5:43 AM, Andy Fan wrote: > > Currently we are using a custom/generic strategy to handle the data skew > > issue. However, it doesn't work well all the time. For example: SELECT * > >

Re: How can the Aggregation move to the outer query

On Tue, May 25, 2021 at 7:42 PM David Rowley wrote: > On Tue, 25 May 2021 at 22:28, Andy Fan wrote: > > > > explain (costs off) select (select count(*) filter (where t2.b = 1) > from m1 t1) > > from m1 t2 where t2.b % 2 = 1; >

Re: How can the Aggregation move to the outer query

On Tue, May 25, 2021 at 10:23 PM Tom Lane wrote: > David Rowley writes: > > On Tue, 25 May 2021 at 22:28, Andy Fan wrote: > >> explain (costs off) select (select count(*) filter (where t2.b = 1) > from m1 t1) > >> from m1 t2 where t2.b % 2 = 1; > >> >

Access root->simple_rte_array instead of Query->rtable for 2 more cases.

nner_rt_fetch, all the tests passed. -- Best Regards Andy Fan (https://www.aliyun.com/) v1-0001-Use-planner_rt_fetch-instead-of-rt_fetch-when-roo.patch Description: Binary data

Re: Hybrid Hash/Nested Loop joins and caching results from subplans

all the > tuples for those 10 distinct values in the cache, then the hit ratio > is going to come out at 99%. 10 misses, for the first time each value > is looked up and the remainder of the 990 calls will be hits. The > number of tuples (and the width of tuples) on the inside of the nested > loop is only relevant to calculating how many cache entries is likely > to fit into hash_mem. When we think cache entries will be evicted > then that makes the cache hit calculation more complex. > > I've tried to explain what's going on in cost_resultcache_rescan() the > best I can with comments. I understand it's still pretty hard to > follow what's going on. I'm open to making it easier to understand if > you have suggestions. > > David > -- Best Regards Andy Fan (https://www.aliyun.com/)

Regarding the necessity of RelationGetNumberOfBlocks for every rescan / bitmap heap scan.

heap scan totally and the rescan for normal heap scan? -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Regarding the necessity of RelationGetNumberOfBlocks for every rescan / bitmap heap scan.

arallel_scan; scan->rs_strategy = NULL; /* set in initscan */ + scan->rs_nblocks = -1; I did the above hacks, and all the existing tests passed. > -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Regarding the necessity of RelationGetNumberOfBlocks for every rescan / bitmap heap scan.

On Sat, May 29, 2021 at 11:23 AM Andy Fan wrote: > Hi: > > I'm always confused about the following codes. > > static void > initscan(HeapScanDesc scan, ScanKey key, bool keep_startblock) > { > ParallelBlockTableScanDesc bpscan = NULL; > bool allow_strat; > bo

Re: A new strategy for pull-up correlated ANY_SUBLINK

here has been no updates on this thread for some time, so this has > been switched as Returned with Feedback. Feel free to open it in the > next commitfest if you plan to continue on this. > > Thank you vignesh C for this, I didn't give up yet, probably I can come back in the following month. -- Best Regards Andy Fan

Unify "In" Sublink to EXIST Sublink for better optimize opportunity

[1] https://www.postgresql.org/message-id/3691.1342650974%40sss.pgh.pa.us [2] https://www.postgresql.org/message-id/can_9jtx7n+cxeqlnu_uhxx+escsgxllungazt6sjvdpt7to...@mail.gmail.com -- Best Regards Andy Fan

Re: Unify "In" Sublink to EXIST Sublink for better optimize opportunity

Hi: On Thu, Oct 6, 2022 at 3:24 PM Andy Fan wrote: > > Due to the implementation of convert_ANY_sublink_to_join, we have > limitations below, which has been discussed at [1] [2]. > > if (contain_vars_of_level((Node *) subselect, 1)) > return NULL; > > I

Question about pull_up_sublinks_qual_recurse

e, */ j->quals = pull_up_sublinks_qual_recurse(root, j->quals, - &j->larg, - available_rels1, - &j->rarg, - child_rels); + jtlink1, + bms_union(available_rels1, child_rels), + NULL, + NULL); /* Return NULL representing constant TRUE */ return NULL; } Any feedback is welcome. -- Best Regards Andy Fan

Re: Question about pull_up_sublinks_qual_recurse

So any hint about this patch's self-review is welcome. -- Best Regards Andy Fan

Re: Question about pull_up_sublinks_qual_recurse

(Pab); Seems both return rows from A which match both semijoin (Pab) and (Pbc). or I misunderstand the above words in the first place? At last, when I checked optimizer/README, it looks like we used a 'nullable side' while it should be 'nonnullable side'? see patch 1 for detai

Re: Unnecessary lateral dependencies implied by PHVs

T Time: 0.123 ms postgres=# explain (costs off) select * from r1 join lateral (select r1.a from r2) on true; QUERY PLAN Nested Loop -> Seq Scan on r1 -> Materialize -> Seq Scan on r2 (4 rows) -- Best Regards Andy Fan

Re: Pulling up direct-correlated ANY_SUBLINK

retty much constrains things to use a nestloop, > so I'm not sure there's anything fundamentally different. > > regards, tom lane > > -- Best Regards Andy Fan test.sql Description: application/sql From 1bdc3b9098851ab1f6897f497daf90c601eca27e Mon Sep 17 00:0

Re: How to started with Contributions

Javascript,Kotlin and Android. I would love to contribute to your > organisation but I would need your help getting started. > Hoping to hear from you soon > > Regards > Joseph Raj Vishal > -- Best Regards Andy Fan

Re: Prefetch the next tuple's memory during seqscans

tuffs. just fyi. pg_prefetch_mem(PageGetItem((Page) dp, lpp)); pg_prefetch_mem(tuple->t_data); pg_prefetch_mem((scan->rs_ctup.t_data); -- Best Regards Andy Fan

A new strategy for pull-up correlated ANY_SUBLINK

Any feedback is welcome. [1] https://www.postgresql.org/message-id/3691.1342650974%40sss.pgh.pa.us [2] https://www.postgresql.org/message-id/can_9jtx7n+cxeqlnu_uhxx+escsgxllungazt6sjvdpt7to...@mail.gmail.com -- Best Regards Andy Fan v1-0001-Pull-up-the-direct-correlated-ANY_SUBLINK-like-EX.patch Description: Binary data

Re: A new strategy for pull-up correlated ANY_SUBLINK

. but I'm not insisting on my method at all. Link [2] might be useful as well. [2] https://www.postgresql.org/message-id/CAKU4AWpi9oztiomUQt4JCxXEr6EaQ2thY-7JYDm6c9he0A7oCA%40mail.gmail.com -- Best Regards Andy Fan

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Hi: I'd start to work on UniqueKey again, it would be great that we can target it to PG 15. The attached patch is just for the notnull_attrs. Since we can't say a column is nullable or not without saying in which resultset, so I think attaching it to RelOptInfo is unavoidable. Here is how my pat

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

he commitfest, but maybe I can devote a block of > time during August. > > regards, tom lane > Looking forward to watching this change closely, thank you both David and Tom! But I still don't understand what the faults my way have , do you mind telling the details? -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

cannot tell them > apart, so, in theory at least, Tom's idea seems better to me. > > David > That's really something I can't do, thanks for the explanation. -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

On Tue, Jul 6, 2021 at 5:34 PM David Rowley wrote: > > On Sun, 4 Jul 2021 at 02:08, Andy Fan wrote: > > I'd start to work on UniqueKey again, it would be great that we can target > > it > > to PG 15. The attached patch is just for the notnull_attrs. Since we ca

Re: Zedstore - compressed in-core columnar storage

Greetings. Thanks for the project. I see the code in github has not been updated for a long time, is it still in active development? Thanks -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Making JIT more granular

ter than the current way. -- Best Regards Andy Fan

Tracking notnull attributes inside Var

5577290%40sss.pgh.pa.us -- Best Regards Andy Fan uniquekey.README Description: Binary data

Re: Making JIT more granular

t; HashAggregate Group Key: a -> Seq Scan on t1 (If Seq Scan is JITed, both HashAggregate & Sort will be JITed.) -- Best Regards Andy Fan

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

On Tue, May 17, 2022 at 6:52 AM Thomas Munro wrote: > On Thu, Mar 24, 2022 at 3:22 PM Andy Fan wrote: > > Here is the latest code. I have rebased the code with the latest master > a1bc4d3590b. > > FYI this is failing with an unexpected plan in the partition_join test: > &

Re: Tracking notnull attributes inside Var

Hi Tom: Thanks for your attention! On Wed, May 18, 2022 at 1:25 AM Tom Lane wrote: > Andy Fan writes: > > notnulls discussion is forked from UniqueKey stuff, you can see the > > attachment > > for the UnqiueKey introduction. Tom raised his opinion to track the > > n

Re: Tracking notnull attributes inside Var

Hi Ashutosh: Nice to see you again! On Tue, May 17, 2022 at 8:50 PM Ashutosh Bapat wrote: > On Sun, May 15, 2022 at 8:41 AM Andy Fan wrote: > > > > > The var in RelOptInfo->reltarget should have nullable = 0 but the var in > > RelOptInfo->baserestrictinfo

Re: Tracking notnull attributes inside Var

of rel_is_nullable_side is small, do we still need think about more effective data struct? Thanks! -- Best Regards Andy Fan not_null_based_on_special_joininfo.diff Description: Binary data

Re: Window Function "Run Conditions"

On Thu, Aug 19, 2021 at 2:35 PM David Rowley wrote: > > On Thu, 19 Aug 2021 at 00:20, Andy Fan wrote: > > In the current master, the result is: > > > > empno | salary | c | dr > > ---++---+ > > 8 | 6000 | 4 | 1 > > > In the p

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

g the commitfest, but maybe I can devote a block of > time during August. > > regards, tom lane Hi Tom: do you get a chance to work on this? Looks like we have to fix this one before we can move on to the uniquekey stuff. -- Best Regards Andy Fan

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

gt;eq_classes, keep it. 2). If t2.pk doesn't exist in RelOptInfo->reltarget after joining, discard it. Step 1 is not so bad since we have RelOptInfo.eclass_indexes. However step 2 looks pretty boring since we have to check on every RelOptInfo and we may have lots of RelOptInfo. Any suggestion

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

On Tue, Jul 13, 2021 at 5:55 PM Andy Fan wrote: > > > 4. Cut the useless UniqueKey totally on the baserel stage based on > >root->distinct_pathkey. If we want to use it anywhere else, I think this > >design is OK as well. for example: group by UniqueKey. > >

Re: UniqueKey on Partitioned table.

On Tue, Apr 6, 2021 at 6:55 PM David Rowley wrote: > > On Tue, 6 Apr 2021 at 22:31, Andy Fan wrote: > > On Wed, Mar 31, 2021 at 9:12 PM Ashutosh Bapat > > wrote: > >> I think the reason we add ECs for sort expressions is to use > >> transitive relation

Re: UniqueKey on Partitioned table.

On Sat, Jul 17, 2021 at 3:45 PM David Rowley wrote: > > On Sat, 17 Jul 2021 at 19:32, Andy Fan wrote: > > SELECT * FROM t1, t2 WHERE t1.pk = t2.pk; > > > > Then when I populate_baserel_uniquekeys for t1, we already have > > EC{Members={t1.pk, t2.pk}} in root-&

Maintain the pathkesy for subquery from outer side information

e. My thinking is we maintain the root->outer_pathkeys first, and then improve the well known function as the first step. What do you think? -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Maintain the pathkesy for subquery from outer side information

On Sat, Jul 24, 2021 at 10:14 PM Tom Lane wrote: > > Andy Fan writes: > > When I am working on the UnqiueKey stuff, I find the following cases. > > SELECT * FROM (SELECT * FROM t offset 0) v ORDER BY a; > > // root->query_keys = A. root->order_pathke

Re: Maintain the pathkesy for subquery from outer side information

we are not that lucky. SELECT pk FROM t; -- Maintain the UniqueKey would be not necessary. However SELECT DISTINCT pk FROM (SELECT volatile_f(a), pk from t) WHERE ..; Maintaining the UniqueKey in subquery is necessary since it is useful outside. -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Hi: I have finished the parts for baserel, joinrel, subquery, distinctrel. I think the hardest ones have been verified. Here is the design overview. 1. Use EC instead of expr to cover more UniqueKey cases. 2. Redesign the UniqueKey as below: @@ -246,6 +246,7 @@ struct PlannerInfo List *eq_cl

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Hi Zhihong, On Mon, Aug 16, 2021 at 12:35 AM Zhihong Yu wrote: > > > > On Sun, Aug 15, 2021 at 7:33 AM Andy Fan wrote: >> >> Hi: >> >> I have finished the parts for baserel, joinrel, subquery, distinctrel. I >> think >> the hardest ones have been

Re: Window Function "Run Conditions"

1 (1 row) In the patched version， the result is: empno | salary | c | dr ---+----+---+ 8 | 6000 | 1 | 1 (1 row) -- Best Regards Andy Fan (https://www.aliyun.com/)

Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Hi: patch v4 fixed the 2 bugs Zhihong reported. Any feedback is welcome. v4-0005-Support-UniqueKey-on-JoinRel.patch Description: Binary data v4-0002-Just-some-utils-functions.patch Description: Binary data v4-0004-Support-UniqueKey-on-BaseRel.patch Description: Binary data v4-0001-Just-re

Re: Table AM modifications to accept column projection lists

are my work so far here [2], However lazy material is not always good. [1] https://stratos.seas.harvard.edu/files/stratos/files/columnstoresfntdbs.pdf [2] https://github.com/zhihuiFan/postgres/tree/lazy_material_v2 -- Best Regards Andy Fan (https://www.aliyun.com/)

New function normal_rand_array function to contrib/tablefunc.

5 means it needs to produce 5 rows in total and the 10 is the average array length, and 1.8 is the minvalue for the random function and 3.5 is the maxvalue. -- Best Regards Andy Fan >From 397dcaf67f29057b80aebbb6116b49ac8344547c Mon Sep 17 00:00:00 2001 From: Andy Fan Date: Sat, 8 Jun 2024

configure error when CFLAGS='-Wall -Werror

t support '-qlanglvl' all the time, why removing the CFLAGS matters. 2. If you are using clang as well, what CFLAGS you use and it works? for example: IIRC, clang doesn't report error when a variable is set but no used by default, we have to add some extra flags to make it. -- Best Regards Andy Fan

<    1   2   3   4   5   6   7   >