I wrote:
> I still haven't figured out why this wasn't a problem in the old
> version of functions.c.
Oh, got it: I was misremembering the API contract for
tuplestore_gettupleslot. There are two possible ways for it to
load the slot with a tuple:
* tuple points into the tuplestore's memory, and
I wrote:
> Hmm. What seems to be going on here is that once the aggfns_trans()
> result gets large enough that the SQL-function-result tuplestore
> decides to spill to disk, when we pull the result tuple back out
> of the tuplestore with tuplestore_gettupleslot we end up with the
> jf_resultSlot h
Alexander Lakhin writes:
> Sorry if I've chosen the wrong thread, but starting from 0313c5dc6,
> the following script:
> CREATE TYPE aggtype AS (a int, b text);
> CREATE FUNCTION aggfns_trans(aggtype[], integer, text) RETURNS aggtype[]
> LANGUAGE sql AS 'SELECT
> array_append($1,ROW($2,$3)::aggt
Alexander Lakhin writes:
> Sorry if I've chosen the wrong thread, but starting from 0313c5dc6,
> the following script:
> ...
> crashes the server for me like this:
> corrupted size vs. prev_size while consolidating
Yup, duplicated here. Thanks for the report!
regards, to
Hello Tom,
Sorry if I've chosen the wrong thread, but starting from 0313c5dc6,
the following script:
CREATE TYPE aggtype AS (a int, b text);
CREATE FUNCTION aggfns_trans(aggtype[], integer, text) RETURNS aggtype[] LANGUAGE sql AS 'SELECT
array_append($1,ROW($2,$3)::aggtype)';
CREATE AGGREGATE a
Bruce Momjian writes:
> On Wed, Apr 16, 2025 at 01:43:46PM -0400, Tom Lane wrote:
>> I'm confused? 0dca5d68d didn't have anything to do with
>> syntax changes, just with when planning happens.
> I was referencing the contrib initialization functions you converted to
> use SQL-standard function b
On Wed, Apr 16, 2025 at 01:43:46PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote:
> >> I agree that we should do something about this. I haven't reviewed
> >> your patches but the approach sounds broadly reasonable.
>
> > Yep, we we
Hi
st 16. 4. 2025 v 19:43 odesílatel Tom Lane napsal:
> Bruce Momjian writes:
> > On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote:
> >> I agree that we should do something about this. I haven't reviewed
> >> your patches but the approach sounds broadly reasonable.
>
> > Yep, we went
Bruce Momjian writes:
> On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote:
>> I agree that we should do something about this. I haven't reviewed
>> your patches but the approach sounds broadly reasonable.
> Yep, we went down the road in PG 18 to convert syntax, and now we have
> to fix
On Mon, Apr 14, 2025 at 10:38:29AM -0400, Robert Haas wrote:
> On Sun, Apr 13, 2025 at 3:23 PM Tom Lane wrote:
> > create function fx(p_summa bigint) returns text immutable strict
> > return ltrim(to_char(p_summa, '999 999 999 999 999 999 999 999'));
> >
> > explain analyze select fx(i) from gener
Hi
po 14. 4. 2025 v 16:38 odesílatel Robert Haas
napsal:
> On Sun, Apr 13, 2025 at 3:23 PM Tom Lane wrote:
> > create function fx(p_summa bigint) returns text immutable strict
> > return ltrim(to_char(p_summa, '999 999 999 999 999 999 999 999'));
> >
> > explain analyze select fx(i) from genera
On Sun, Apr 13, 2025 at 3:23 PM Tom Lane wrote:
> create function fx(p_summa bigint) returns text immutable strict
> return ltrim(to_char(p_summa, '999 999 999 999 999 999 999 999'));
>
> explain analyze select fx(i) from generate_series(1,100) as i(i);
>
> you arrive at the rude discovery tha
In the thread that led up to commit 0dca5d68d [1], we'd convinced
ourselves that the new implementation was faster than the old.
So I was sad to discover that there are common cases where it's
a good bit slower. We'd focused too much on test methods like
do $$
begin
for i in 1..1000 loop
13 matches
Mail list logo
