Andres doesn't have such time so far:(
> Robert Haas writes:
>
>> On Wed, May 22, 2024 at 9:46 PM Andy Fan wrote:
>>> Please give me one more chance to explain this. What I mean is:
>>>
>>> Take SELECT f(a) FROM t1 join t2...; for example,
>>>
les
> having been cleaned up by on-access pruning.
Good to know this case. if we update the pg_stats_xx metrics when on-access
pruning, would it is helpful on this?
> - Larger tables with occasional lock conflicts cause autovacuum to be
> cancelled and restarting from scratch over and over. If that happens before
> the second table scan, this can easily eat up the whole cost budget without
> making forward progress.
Off-peak time + manual vacuum should be helpful I think.
--
Best Regards
Andy Fan
Andy Fan writes:
>
>> - Longrunning transaction prevents increasing relfrozenxid, we run autovacuum
>> over and over on the same relation, using up the whole cost budget. This is
>> particularly bad because often we'll not autovacuum anything else, building
&
the first use of outputTapes[x], it stores (1, 3, 5, 7),
and later (2, 4, 6, 8) are put into it. so the overall of (1, 3, 5, 7,
2, 4, 6, 8) are not sorted? Where did I go wrong?
--
Best Regards
Andy Fan
Heikki Linnakangas writes:
> On 30/06/2024 12:48, Andy Fan wrote:
>> for example, at the first use of outputTapes[x], it stores (1, 3, 5,
>> 7),
>> and later (2, 4, 6, 8) are put into it. so the overall of (1, 3, 5, 7,
>> 2, 4, 6, 8) are not sorted? Where di
much it can improve in an ideal case, is it possible to forecast it
somehow? I ask it here because both cases are optimizing for CPU cache..
--
Best Regards
Andy Fan
find anything wrong in the currrent
patch, and the above stuff can be categoried into "furture improvement"
even it is worthy to.
--
Best Regards
Andy Fan
>From 48c2e03fd854c8f88f781adc944f37b004db0721 Mon Sep 17 00:00:00 2001
From: Andy Fan
Date: Sat, 8 Jun 2024 13:21:08 +080
d of CPUs.
a). Intel Xeon Processor (Icelake) for my ECS
b). Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz at Mac.
My ECS reports " branch-misses", probabaly because it
runs in virtualization software , and Mac doesn't support perf yet :(
--
Best Regards
Andy Fan
Andy Fan writes:
I just realize all my replies is replied to sender only recently,
probably because I upgraded the email cient and the short-cut changed
sliently, resent the lastest one only
>>> Suppose RBTree's output is:
>>>
>>> batch-1 at RBTree:
&
), lock the
> same 2pc will cause panic.
>
> Is the above scenario reasonable, and do you have any good ideas for
> fixing this bug?
>
> Thanks & Best Regard
>
>
--
Best Regards
Andy Fan
b where a@->'a' = 2;
65ms.
Is this the right way to go? Testcase, document and catalog version are
updated.
--
Best Regards
Andy Fan
v1-0001-Add-jsonb-operator-to-return-a-numeric-directly.patch
Description: Binary data
On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
> On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote:
> >
> > Hi:
> >
> > Currently if we want to extract a numeric field in jsonb, we need to use
> > the following exp
Hi Matthias:
On Wed, Aug 2, 2023 at 7:33 AM Andy Fan wrote:
>
>
> On Tue, Aug 1, 2023 at 7:03 PM Matthias van de Meent <
> boekewurm+postg...@gmail.com> wrote:
>
>> On Tue, 1 Aug 2023 at 06:39, Andy Fan wrote:
>> >
>> > Hi:
>> >
>> &g
with all the existing operators.
select 1 from tb where (a->'a')::numeric = 2; 30.56ms
select 1 from tb where (a->>'a')::numeric = 2; 29.43ms
select 1 from tb where (a@->'a') = 2; 14.80ms
[1] https://commitfest.postgresql.org/44/4476/
--
Best Re
_window_path. I think the startup_tuples should be
independent with the physical path, maybe we can cache it somewhere to
save some planning cycles?
Thanks for the patch!
--
Best Regards
Andy Fan
l, if we really care about the number of operators, I'm OK
with just let users use the function directly, like
jsonb_field_as_numeric(jsonb, 'filedname')
jsonb_field_as_timestamp(jsonb, 'filedname');
jsonb_field_as_timestamptz(jsonb, 'filedname');
jsonb_field_as_date(jsonb, 'filedname');
it can save an operator and sloves the readable issue.
--
Best Regards
Andy Fan
ic = 2; 31ms.
> > select 1 from tb where (a@->'a') = 2; 15ms
>
> What's tb here?
>
This is my first post. Copy it here again.
create table tb (a jsonb);
insert into tb select '{"a": 1}'::jsonb from generate_series(1, 10)i;
--
Best Regards
Andy Fan
> I don't like it too much, but it is better than introduction new operator
>
Good to know it. Naming operators is a complex task if we add four.
> We already have the jsonb_extract_path and jsonb_extract_path_text
> function.
>
I can't follow this. jsonb_extract_path returns a jsonb, which is far
away from
our goal: return a numeric effectively?
I can imagine to usage "anyelement" type too. some like
> `jsonb_extract_path_type(jsonb, anyelement, variadic text[] )`
>
Can you elaborate this please?
--
Best Regards
Andy Fan
Hi:
On Thu, Aug 3, 2023 at 8:34 PM Chapman Flack wrote:
> On 2023-08-03 03:53, Andy Fan wrote:
> > I didn't realize timetime types are binary compatible with SQL,
> > so maybe we can have some similar optimization as well.
> > (It is a pity that timestamp(tz) are
On Thu, Aug 3, 2023 at 7:29 PM David Rowley wrote:
> Thanks for having a look at this.
>
> On Thu, 3 Aug 2023 at 18:49, Andy Fan wrote:
> > 1. ORDER BY or PARTITION BY
> >
> > select *, count(two) over (order by unique1) from tenk1 limit 1;
> > DEB
ng something like this
or I misunderstood you?
>
--
Best Regards
Andy Fan
so we can call it with
a->'a'::numeric.
select numeric('{"a":11}'->'a'); --fail.
> select "numeric"('{"a":11}'::jsonb->'a'); --ok
>
The double quotes look weird to me. but it looks like a common situation.
select numeric('1'::int); -- failed.
select "numeric"('1'::int); -- ok.
--
Best Regards
Andy Fan
Hi Tom:
On Fri, Aug 4, 2023 at 3:13 AM Tom Lane wrote:
> Andy Fan writes:
> >> If you use explicit cast, then the code should not be hard, in the
> >> rewrite stage all information should be known.
>
> > Can you point to me where the code is for the XML stuff?
&g
b where not (a->'a')::boolean;
Time: 12.894 ms
select 1 from tb where (a->'b')::int2 = 1;
Time: 16.847 ms
select 1 from tb where (a->'b')::int4 = 1;
Time: 17.105 ms
select 1 from tb where (a->'b')::int8 = 1;
Time: 16.720 ms
select 1 from
; filtered by jsonb_cast_is_optimized. So the message should be changed or it
> needs a comment.
>
Yes, the double check is not necessary, that is removed in the attached v4
patch.
--
Best Regards
Andy Fan
v4-0001-Optimize-extracting-a-given-data-type-from-jsonb.patch
Description: Binary data
o hear more options from more experienced people,
this issue also confused me before. and I'm neutral to this now.
after we get an agreement on this, I will update the patch
accordingly.
--
Best Regards
Andy Fan
Hi:
On Mon, Aug 7, 2023 at 7:51 PM Andy Fan wrote:
> Hi Jian:
>
> Thanks for the review!
>
> compared with jsonb_numeric. I am wondering if you need a free *jb.
>> elog(INFO,"jb=%p arg pointer=%p ", jb, PG_GETARG_POINTER(0));
>> says there two are not the
emory and it doesn't cost
much. It would be handy than estimating that by something
like select count(*) from pg_class.
I think, for example, if we find relcache using too much memory,
it is a signal that the user may use too many partitioned tables.
--
Best Regards
Andy Fan
T_FIELD.
> Are there opportunities for a similar benefit if applied
> over F_JSONB_ARRAY_ELEMENT and/or F_JSONB_EXTRACT_PATH?
>
Yes, we do have similar opportunities for both functions. v5 attached for
this.
--
Best Regards
Andy Fan
v5-0001-optimize-casting-jsonb-to-a-given-type.patch
Description: Binary data
ves
a fix? Or shall I define jsonb_object_field_int2/int8 to avoid this?
This is an unresolved issue at the latest patch.
--
Best Regards
Andy Fan
sonb_object_field?
I guess no. IIUC, our goal will still be missed in this way.
--
Best Regards
Andy Fan
ok for the current supported type. but I'm not sure
about the future or if we still have a better solution.
v6 is attached. any feedback is welcome!
--
Best Regards
Andy Fan
v6-0001-optimize-casting-jsonb-to-a-given-type.patch
Description: Binary data
ot cleaned well before this run. you can try
'make installcheck' with a pretty clean setup or run 'make check'
directly to verify this.
--
Best Regards
Andy Fan
UMERICOID);
+
+ /* Mock a valid datum for !constbyval type. */
+ if (fexpr->funcresulttype == NUMERICOID)
+ target->constvalue =
DirectFunctionCall1(numeric_in, CStringGetDatum("0"));
--
Best Regards
Andy Fan
don't need to touch to cast functions, and we can
> simply implement similar functions for other non atomic types.
>
What do you mean by "atomic type" here? If you want to introduce some new
framework, I think we need a very clear benefit.
--
Best Regards
Andy Fan
onally I'm not willing to creating some
thing new & heavy. However I'm open to see what others say.
--
Best Regards
Andy Fan
Index Scan using pg_class_relname_nsp_index on pg_catalog.pg_class
Output: oid, relname
Index Cond: (pg_class.relnamespace = '28601'::oid)
Filter: (has_table_privilege(pg_class.oid, 'SELECT'::text) AND
(pg_class.relkind = ANY ('{r,m,v}'::"char"[])))
Patch is attached.
--
Best Regards
Andy Fan
v1-0001-Avoid-a-potential-unstable-testcase.patch
Description: Binary data
Index Cond: (pg_class.relnamespace = '28601'::oid)
v2 attached.
--
Best Regards
Andy Fan
v2-0001-Avoid-a-potential-unstable-testcase.patch
Description: Binary data
ugh there for
discussion.
--
Best Regards
Andy Fan
On Tue, Aug 15, 2023 at 1:24 PM Pavel Stehule
wrote:
> Hi
>
> út 15. 8. 2023 v 5:24 odesílatel Andy Fan
> napsal:
>
>>
>>> jsonb_extract_xx_type just cares about the argtype, but
>>> 'explain select xx' will still access the const->co
update with the correct patch..
v8-0001-optimize-casting-jsonb-to-a-given-type.patch
Description: Binary data
Hi jian:
On Thu, Aug 17, 2023 at 12:32 AM jian he
wrote:
> On Wed, Aug 16, 2023 at 2:28 PM Andy Fan wrote:
> >
> > update with the correct patch..
>
> regression=# select proname, pg_catalog.pg_get_function_arguments(oid)
> from pg_proc
> where proname
ed in the const.constvalue is as well since
'explain select ' to access it to show it as a string.
Datum(0) as the constvalue will crash in this sense. That's why
makeDummyConst was introduced.
> something like "assertion of
> 'internal'-to-foo binary coercibility, vouched by a prosupport
> function", would that be a bad thing?
>
I can't follow this as well. Could you provide the function prototype
here?
--
Best Regards
Andy Fan
yVal);
+
+ if (consttype == NUMERICOID)
+ val = DirectFunctionCall1(numeric_in, CStringGetDatum("0"));
+ else if (!typByVal)
+ elog(ERROR, "create dummy const for type %u is not
supported.", consttype);
+
+ /* XXX: here I assume con
put anything in this arg, so I put an OID const here",
seems nothing is wrong. Compared with the makeRelableType method,
I think the current method is more straightforward. Compared with
anyelement, it avoids the creation of makeDummyConst which I'm not
sure the implementation is alway
s showimplicit is always
true for args in this case, checking the implementation of
get_rule_expr, I found PG behavior like this in many places.
--
Best Regards
Andy Fan
o build the inner table first for this
optimization? so hash join and sort merge should be OK, but nestloop should
be impossible unless I missed something.
--
Best Regards
Andy Fan
（Just relalized this was sent to chap in private, resent it again).
On Mon, Aug 21, 2023 at 6:50 PM Andy Fan wrote:
>
>
> On Mon, Aug 21, 2023 at 11:19 AM Chapman Flack
> wrote:
>
>> On 2023-08-20 21:31, Andy Fan wrote:
>> > Highlighting the user case of makeR
lt at last and then pg doesn't
know how to output an internal data type. This is kind of in conflict
with our goal.
So currently the only choices are: PATCH 001 or PATCH 001 + 002.
https://www.postgresql.org/message-id/CAKU4AWrs4Pzajm2_tgtUTf%3DCWfDJEx%3D3h45Lhqg7tNOVZw5YxA%40mail.gmail.com
--
Best Regards
Andy Fan
On Tue, Aug 22, 2023 at 5:43 PM Richard Guo wrote:
>
> On Mon, Aug 21, 2023 at 8:34 PM Andy Fan wrote:
>
>> This feature looks good, but is it possible to know if we can prune
>> any subnodes before we pay the extra effort (building the Hash
>> table, for each row...
ng for every case, like we only
care about '=' operator which is the most common case, it should be
easier than the case here since we just need to know if only 1 partition
will survive after pruning, but don't care about which one it is. I'd like
to discuss in another thread, and leave this thread for Richard's patch
only.
--
Best Regards
Andy Fan
Andy Fan writes:
> Here is latest version, nothing changed besides the rebase to the latest
> master. The most recent 3 questions should be addressed.
>
> - The error message compatible issue [1] and the Peter's answer at [2].
> - Peter's new question at [2] and my answ
list if you do that.
Thanks for your review suggestion, I will get to this very soon if once
I get time, I hope it is in 4 weeks.
[1]
https://www.postgresql.org/message-id/7mlamswjp81p.fsf%40e18c07352.et15sqa
--
Best Regards
Andy Fan
much success and few reverts!
>
Congratulations to both, Well deserved!
--
Best Regards
Andy Fan
t
> observing any errors or crashes.
Good to know that.
> I'll try to look harder at the next patch revision.
Thank you!
--
Best Regards
Andy Fan
Andy Fan writes:
> Hello everyone,
>
>> After some more thoughts about the diference of the two ideas, then I
>> find we are resolving two different issues, just that in the wrong index
>> choose cases, both of them should work generally.
>
> Here is the fo
Hello Justin,
Thanks for showing interest on this!
> On Sun, Apr 28, 2024 at 10:07:01AM +0800, Andy Fan wrote:
>> 's/estimiatedcluases/estimatedclauses/' typo error in the
>> commit message is not fixed since I have to regenerate all the commits
>
> Maybe y
heory is that relation is single-row if it has an UK such that each of
> its ECs meets at least one of the following conditions:
>
> a) contains a constant
True.
>
> b) contains a column of a relation which has already been proven single-row.
True, not sure if it is easy to tell.
> b) is referenced by an UK of a relation which has already been proven
> single-row.
I can't follow here...
>
> I think that in the example above, an EC {t1.e, t2.id} should exist. So when
> checking whether 't2' is single-row, the condition b) cam be ised: the UK of
> 't2' should reference the EC {t1.e, t2.id}, which in turn contains the
> column t1.e. And 't1' is unique because its EC meets the condition a). (Of
> course you need to check em_jdomain before you use particular EM.)
I think the existing rule 1 for joinrel works well with the singlerow
case naturally, what can be improved if we add the theory you suggested
here?
--
Best Regards
Andy Fan
he WORKER dump the tuples into Sharedsort struct
and let the LEADER merge them directly. I think this aim of this design
is it is potential to save a mergeruns. In the current patch, worker dump
to local tuplesort and mergeruns it and then leader run the merges
again. I admit the goal of this patch is reasonable, but I'm feeling we
need to adapt this way conditionally somehow. and if we find the way, we
can apply it to btbuild as well.
--
Best Regards
Andy Fan
ker 1-block by 1-block, we will have a
serious issue like here. If we can have N-block by N-block, and N-block
is somehow fill the work_mem which makes the dedicated temp file, we
can make things much better, can we?
--
Best Regards
Andy Fan
llow this, I won't object ...
Agree with this. I am more interested with understanding the whole
design and the scope to fix in this patch, and then I can do some code
review and testing, as for now, I still in the "understanding design and
scope" stage. If I'm too slow about this patch, please feel free to
commit it any time and I don't expect I can find any valueable
improvement and bugs. I probably needs another 1 ~ 2 weeks to study
this patch.
--
Best Regards
Andy Fan
hink we need to add the following 2 items?
- 9f133763961e280d8ba692bcad0b061b861e9138 this is an optimizer
transform improvement.
- a8a968a8212ee3ef7f22795c834b33d871fac262 this is an optimizer costing
improvement.
Both of them can generate a better plan on some cases.
--
Best Regards
Andy Fan
ckTableScanWorkerData.phsw_chunk_size is designed
for this.
> The problem is that if the scan wraps around, then one of the TID lists
> for a given worker will have the min TID and max TID, so it will overlap
> with every other TID list for the same key in that worker. And when the
> worker does the merging, this list will force a "full" merge sort for
> all TID lists (for that key), which is very expensive.
OK.
Thanks for all the answers, they are pretty instructive!
--
Best Regards
Andy Fan
Bruce Momjian writes:
> On Sat, May 11, 2024 at 01:27:25PM +0800, Andy Fan wrote:
>>
>> Hello Bruce,
>>
>> > I have committed the first draft of the PG 17 release notes; you can
>> > see the results here:
>> >
>> >https://m
s any value (NULL
> or NOT NULL) because it describes the whole relation rather than particular
> row. I consider UniqueKey to be a set of expressions. How about
> uniquekey_expression_nullable() ?
uniquekey_expression_nullable() is a better name, I will use it in the
next version.
IIUC, we have reached to the agreement based on your latest response for
the most of the questions. Please point me if I missed anything.
>> > Of course one problem is that the number of combinations can grow
>> > exponentially as new relations are joined.
>>
>> Yes, that's why "rule 1" needed and "How to reduce the overhead" in
>> UniqueKey.README is introduced.
>
> What if we are interested in unique keys of a subquery, but the subquery has
> no DISTINCT clause?
I agree we should remove the prerequisite of "use_for_distinct".
--
Best Regards
Andy Fan
ast, this probably is my first non-trival patchs which has multiple
authors, I don't want myself is the bottleneck for the coorperation, so
if you need something to do done sooner, please don't hesitate to ask me
for it explicitly.
Here is my schedule about this. I can provide the next version based
our discussion and your patches at the eariler of next week. and update
the UniqueKey.README to make sure the overall design clearer. What I
hope you to pay more attention is the UniqueKey.README besides the
code. I hope the UniqueKey.README can reduce the effort for others to
understand the overall design enormously.
--
Best Regards
Andy Fan
ot, clauses, varRelid,
jointype,
+
rather than
+ if (clauselist_selectivity_hook)
+ *return* clauselist_selectivity_hook(root, clauses, ..)
?
--
Best Regards
Andy Fan
Hi Robert,
> Andy Fan asked me off-list for some feedback about this proposal. I
> have hesitated to comment on it for lack of having studied the matter
> in any detail, but since I've been asked for my input, here goes:
Thanks for doing this! Since we have two totally dif
Andy Fan writes:
> Hi Robert,
>
>> Andy Fan asked me off-list for some feedback about this proposal. I
>> have hesitated to comment on it for lack of having studied the matter
>> in any detail, but since I've been asked for my input, here goes:
>
> Thank
Robert Haas writes:
> On Tue, May 21, 2024 at 10:02 PM Andy Fan wrote:
>> One more things I want to highlight it "syscache" is used for metadata
>> and *detoast cache* is used for user data. user data is more
>> likely bigger than metadata, so cache size contr
Nikita Malakhov writes:
> Hi,
> Andy, glad you've not lost interest in this work, I'm looking
> forward to your improvements!
Thanks for your words, I've adjusted to the rhythm of the community and
welcome more feedback:)
--
Best Regards
Andy Fan
Andrei Lepikhov writes:
> On 20/5/2024 15:52, Andy Fan wrote:
>> Hi Andrei,
>>
>>> On 4/3/24 01:22, Tomas Vondra wrote:
>>>> Cool! There's obviously no chance to get this into v18, and I have stuff
>>>> to do in this CF. But I'll take
Robert Haas writes:
> On Wed, May 22, 2024 at 9:46 PM Andy Fan wrote:
>> Please give me one more chance to explain this. What I mean is:
>>
>> Take SELECT f(a) FROM t1 join t2...; for example,
>>
>> When we read the Datum of a Var, we read it from tts->tts_
d enough for its purpose? If so, we can
save the memory for OffsetNumber for each GinTuple.
Item 5) and 6) needs some coding and testing. If it is OK to do, I'd
like to take it as an exercise in this area. (also including the item
1~4.)
--
Best Regards
Andy Fan
e big improvement for planning
a big number of partitioned table.
--
Best Regards
Andy Fan
ov at [1] and the options like '--diff-file' or
'--select-script' looks very promising, but all of them needs some time
to try it out and then automate it. so I'd like to ask first..
[1] https://github.com/linux-test-project/lcov/blob/master/README
--
Best Regards
Andy Fan
thers. pg_read_binary_file is better, but file
system cache still there. should we expose a direct-io option for
pg_read_binary_file?
--
Best Regards
Andy Fan
gestion in the new attached version. They are not
only some cleaner APIs for user and but also some cleaner implementation
in core, Thank for this suggestion as well.
Sorry for the late response, just my new posistion is bit of busy that I
don't have enough time on community work.
--
Best Regards
Andy Fan writes:
>>> My suggestion would be to mirror the signatures of the core random()
>>> functions more closely, and have this:
>>>
>>> 1). rand_array(numvals int, minlen int, maxlen int)
>>> returns setof float8[]
>>>
> .
-sort tuples into tape
directly rather than inserting them into tuplesort's memory and dump
them into tape without a sort. However I can't define a clean API for
the former case. c). create-index is a maintenance work, improving it by
30% would be good, but if we just improve it by <3, it looks not very
charming in practice.
So my option is if we can have agreement on 0008, then we can final
review/test on the existing code (including 0009), and leave further
improvement as a dedicated patch.
What do you think?
[1] https://www.postgresql.org/message-id/87le0iqrsu.fsf%40163.com
--
Best Regards
Andy Fan
) we'll be able to see a meaningfully larger performance
> improvement.
Personally I am more fans of your "buffer writetup" idea, but not the
same interests with the tuplesort_beginsortedrun /
tuplesort_endsortedrun. I said the '3%' is for the later one and I
guess you understand it as the former one.
>
>> So my option is if we can have agreement on 0008, then we can final
>> review/test on the existing code (including 0009), and leave further
>> improvement as a dedicated patch.
>
> As mentioned above, I think I could update the patch for a btree
> implementation that also has immediate benefits, if so desired?
If you are saying about the buffered-writetup in tuplesort, then I think
it is great, and in a dedicated thread for better exposure.
--
Best Regards
Andy Fan
errmsg("minlen and maxlen must be greater than
> zero.")));
>
> Here the minlen might be zero, so the error message is incorrect.
> How about use "minlen must be greater than or equal to zero"?
Yes, you are right. A new version is attached, thanks for
where the patch doesn't help otherwise). But then in other cases it
> doesn't help at all, and 0010 helps.
Yes, I'd like to see these improvements both 0008 and 0010 as a
dedicated improvement.
--
Best Regards
Andy Fan
Japin Li writes:
> On Wed, 28 Aug 2024 at 12:27, Andy Fan wrote:
>> Japin Li writes:
>>
> Nitpick, the minlen is smaller than maxlen, so the maxlen cannot be zero.
>
> After giving it some more thought, it would also be helpful if maxlen is
> equal to minlen.
>
&
some infrastructure changes. the
memcpy in step 4 is: "1.27% __memcpy_avx_unaligned_erms" in my above
case.
What do you think?
--
Best Regards
Andy Fan
PG18, but I'd be happy for some
> assistance if you're willing.
I see you did many amazing work with cache-line-frindly data struct
design, branch predition optimization and SIMD optimization. I'd like to
try one myself. I'm not sure if I can meet the target, what if we handle
the out/in function separately (can be by different people)?
--
Best Regards
Andy Fan
David Rowley writes:
> On Fri, 30 Aug 2024 at 12:10, Andy Fan wrote:
>> What would be the extra benefit we redesign all the out functions?
>
> If I've understood your proposal correctly, it sounds like you want to
> invent a new "print" output function for each
David Rowley writes:
> On Fri, 30 Aug 2024 at 13:04, Andy Fan wrote:
>>
>> David Rowley writes:
>> > If there's anywhere we call output functions
>> > where the resulting value isn't directly appended to a StringInfo,
>> > then we could j
m back again for
> output strings larger than L1.
The attached is PoC of this idea, not matter which method are adopted
(rewrite all the outfunction or a optional print function), I think the
benefit will be similar. In the blew test case, it shows us 10%+
improvements. (0.134ms vs 0
Andy Fan writes:
> The attached is PoC of this idea, not matter which method are adopted
> (rewrite all the outfunction or a optional print function), I think the
> benefit will be similar. In the blew test case, it shows us 10%+
> improvements. (0.134ms vs 0.110ms)
After working o
Hello David & Andreas,
> On 8/29/24 1:51 PM, David Rowley wrote:
>> I had planned to work on this for PG18, but I'd be happy for some
>> assistance if you're willing.
>
> I am interested in working on this, unless Andy Fan wants to do this
> work. :) I b
,4,8}/float{4,8} in pg_proc for '->'
operator, not only numeric.
2. user may use OpExpr, like (jb->'x')::numeric, user may also use
FuncExpr, like (jsonb_object_field(a, 'x'))::numeric.
--
Best Regards
Andy Fan
ose).
so I want some of you can have a double check on these function bodies, if
anything wrong, I can change it easlier (vs I made the same efforts on
all the type function). does it make sense?
Patch 0001 ~ 0003 is something related and can be reviewed or committed
seperately. and 0004 is the main
is doing.
OK, you are right, your new names should be better.
> Also, the function accepts float8 minval and maxval arguments, and
> then simply ignores them and returns random float8 values in the range
> [0,1), which is highly counterintuitive.
This is a obvious bug and it only exists in float8 case IIUC, will fix
it in the next version.
--
Best Regards
Andy Fan
Andy Fan writes:
(just noticed this reply is sent to Jim privately, re-sent it to
public.)
> Hi Jim,
>
>>
>> When either minval or maxval exceeds int4 the function cannot be
>> executed/found
>>
>> SELECT * FROM normal_rand_array(5, 10, 8, 42::bigint);
>
key' change can cause noticeable change,
especially there is just one function call in the 'if-statement' (I am
thinking more instrucments in the if-statement body, more changes it can
cause).
+ if (unlikely(winstate->buffer == NULL))
+ prepare_tuplestore(winstate);
--
Best Regards
Andy Fan
les for a held cursor or a PORTAL_ONE_RETURNING,
> PORTAL_ONE_MOD_WITH, or PORTAL_UTIL_SELECT query.". Attached is a
> patch for that.
Patch looks good to me.
All the codes of PortalRun & FillPortalStore & PortalRunSelect are
consistent with this idea.
--
Best Regards
Andy Fan
tartup_cost in cost_seqscan, I must be wrong now, but I want to know
where is it.
> and I'm far from sure that it would not have any negative
> side-effects.
Yes, I think it is a semantics correct than before however.
--
Best Regards
Andy Fan
? I tried to think it as root->distinct_pathkeys,
however I
didn't fully understand where root->distinct_pathkeys is used for as well.
[1]
https://www.postgresql.org/message-id/CAKU4AWq%3DwWkAo-CDOQ5Ea6UwYvZCgb501w6iqU0rtnTT-zg6bQ%40mail.gmail.com
--
Best Regards
Andy Fan
d say this case worth the troubles. My
current
implementation looks not cool, so any suggestion to research further is
pretty
welcome.
--
Best Regards
Andy Fan
401 - 500 of 678 matches
Mail list logo
