MAX_INTERVAL_PRECISION, true);
*cp = '\0';
}
@@ -4665,16 +4666,16 @@ EncodeInterval(struct pg_itm *itm, int style, char *str)
}
else if (has_day)
{
- sprintf(cp, "%lld %lld:%02d:",
- (long long) mday, (long long) hour, min);
- cp += strlen(cp);
Andy Fan writes:
> Just to be clearer, I'd like work on the out function only due to my
> internal assignment. (Since David planned it for PG18, so it is better
> say things clearer eariler). I'd put parts of out(print) function
> refactor in the next 2 days. I think it deserves a double check bef
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 believe that optimizing the out, in and se
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 on more {type}_
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 believe that optimizing the out, in and send functions would
be worth the pai
David Rowley writes:
> On Fri, 30 Aug 2024 at 03:33, Tom Lane wrote:
>>
>> David Rowley writes:
>> > [ redesign I/O function APIs ]
>> > I had planned to work on this for PG18, but I'd be happy for some
>> > assistance if you're willing.
>>
>> I'm skeptical that such a thing will ever be practi
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 just use a temporary StringInfo to obtain the cstring
>> >
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 just use a temporary StringInfo to obtain the cstring
> > and its length.
>
> I think th
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 type to output the Datum
> onto a
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 type to output the Datum
onto a StringInfo, if that's the case, w
On Fri, 30 Aug 2024 at 03:33, Tom Lane wrote:
>
> David Rowley writes:
> > [ redesign I/O function APIs ]
> > I had planned to work on this for PG18, but I'd be happy for some
> > assistance if you're willing.
>
> I'm skeptical that such a thing will ever be practical. To avoid
> breaking un-con
David Rowley writes:
Hello David,
>> My high level proposal is define a type specific print function like:
>>
>> oidprint(Datum datum, StringInfo buf)
>> textprint(Datum datum, StringInfo buf)
>
> I think what we should do instead is make the output functions take a
> StringInfo and just pass it
David Rowley writes:
> [ redesign I/O function APIs ]
> I had planned to work on this for PG18, but I'd be happy for some
> assistance if you're willing.
I'm skeptical that such a thing will ever be practical. To avoid
breaking un-converted data types, all the call sites would have to
support bo
On Thu, 29 Aug 2024 at 21:40, Andy Fan wrote:
>
>
> Usually I see printtup in the perf-report with a noticeable ratio.
> Part of the slowness is caused by "memcpy", "strlen" and palloc in
> outfunction.
Yeah, it's a pretty inefficient API from a performance point of view.
> My high level propos
Usually I see printtup in the perf-report with a noticeable ratio. Take
"SELECT * FROM pg_class" for example, we can see:
85.65% 3.25% postgres postgres [.] printtup
The high level design of printtup is:
1. Used a pre-allocated StringInfo DR_printtup.buf to store data for
each tuples.
15 matches
Mail list logo
