- Neason & ninja test
had failed.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
some issues on the platform
2) CFbot has some issues on the platform
or both. Any idea?
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
on.
>
> +1
The patch pushed. thanks.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
In the "Asynchronous Command Processing" section of libpq.sgml,
there's a line which misses a comma at the end. Attached patch should
fix it. I am going to push attached patch into master and
REL_17_STABLE branches if there's no objection.
Best regards,
--
Tatsuo Ishii
SRA OS
orage: Disk Maximum Storage: 65kB
>
> Thank you for testing that. I've just pushed a patch to bump it up to 2500.
>
> I suspect the buildfarm didn't catch this due to the tuplestore
> consuming enough memory in MEMORY_CONTEXT_CHECKING builds.
David,
Christoph,
nt with real data and didn't find any bugs, so It is ready for
> committer status.
One thing I worry about the patch is, now the non-nulls array
optimization was removed. Since then I have been thinking about if
there could be other way to optimize searching for non null rows.
Best r
=5721e5453ebc59360b6756fe72d7499c4a02177c;hpb=cd3c45125d2d92e86ad7530b162562a23d063c26
Same thing can be said to "blob" and "blame".
"history" seems to be Ok.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Attached version removes the non-nulls array. That seems to speed
> everything up. Running the above query with 1 million rows averages 450ms,
> similar when using lead/lag.
Great. However, CFbot complains about the patch:
https://cirrus-ci.com/task/6364194477441024
Best reagards,
587.05
6000843.23
70001196.177
80001508.52
90001920.593
1 2514.069
As you can see, when the number of rows = 1k, it took 28 ms. For 10k
rows, it took 2514 ms, which is 86 times slower than the 1k case. Can
we enhance this?
Graph attached.
Best reagards,
--
Tatsuo Is
>> On Thu, Feb 20, 2025 at 10:53 PM Tatsuo Ishii wrote:
>> > I noticed some of entries are shown with the author field being empty.
>> > e.g. https://commitfest.postgresql.org/patch/5525/
>>
>> When the layout of https://commitfest.postgresql.org/52/ changed,
st:pgtest as user & password for the http auth. If you want to
> make edits you need to create a new account, read-only doesn't need an
> account.
>
> [1]: https://commitfest-test.postgresql.org/
I noticed some of entries are shown with the author field being empty.
e.g.
sts.
I applied the v7 patch and ran regression and tap test. There was no
errors. Great!
BTW, I noticed that in the code path where
ignorenulls_getfuncarginframe() is called, WinSetMarkPosition() is
never called?
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.srao
> Nathan Bossart writes:
>> On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
>>> My thought was that duplicating the logic isn't so bad, as attached.
>
>> WFM!
>
> It does fix the problem here, so I'll make it so.
Sorry for the problem and
s_getfuncarginframe and the code path in
WinGetFuncArgInFrame, which takes care of EXCLUDE like this.
case FRAMEOPTION_EXCLUDE_CURRENT_ROW:
if (abs_pos >= winstate->currentpos &&
winstate->curren
e it in the array and return 6.
>
> It will be unordered when the EXCLUDE clause is used but the code
> should handle this correctly.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
T ROW);
(gdb) p *winobj->win_nonnulls @ winobj->nonnulls_len
$8 = {1, 0, 3, 6, 5}
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
e PARSER_RESPECT_NULLS 1
+#define NO_NULLTREATMENT 0
This looks strange to me. Why do you start the define value from 4
down to 0? Also there is no place to use RESPECT_NULLS. Do we need it?
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ls stores currentpos in
a partition, when the partition ends, win_nonnulls needs to be
reset. Otherwise, it mistakenly represents currentpos in the previous
partition.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
are called in the per tuple memory context,
which means win_nonnulls disappears when next tuple is supplied to the
window function. If my understanding is correct, winobj->win_nonnulls
needs to survive across processing tuples.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
GNORE NULLS OVER (ORDER BY x) FROM
(VALUES(1,NULL),(2,2),(3,NULL)) AS v(x,y);
x | y | lead
---+---+--
1 | |2
2 | 2 |2
3 | |2
(3 rows)
I think correct result of "lead" column is 2, NULL, NULL.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: htt
ould add an API to WinObject access functions to
export ignore_nulls value. Then let each window function check it. If
the window function should not take IGNORE/RESPECT NULLS option, throw
an error.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
nt that to be hard-wired in some centralized
> spot.
I agree. That's the right direction.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Tatsuo Ishii writes:
>>> The latest version restricts it to lag, lead, first_value, last_value,
>>> and nth_value. We can extend it in a subsequent patch if there's
>>> demand?
>
>> The restriction is required by the SQL standard. So I don't thi
ignorenulls_getfuncarginframe() does not take account EXCLUSION frame
options.
(2) New member ignore_nulls are added to some structs. Its value is 0,
1 or -1. It's better to use a DEFINE for the value of ignore_nulls,
rather than 0, 1, or -1.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
Englis
> No objections here.
V4 patch pushed. Thanks.
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ize);
Note, I changed "initsize > 0" to "initsize >= 1" to better match with
the comment:
> * The valid range for 'initsize' is 1 to MaxAllocSize.
If there's no objection, I am going to commit the patch.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
Eng
x27;s worth saving whatever cycles we can.
Ok, I have created v3 patch to do more inlining as you suggested. With
the patch I confirmed that there's no call to functions except palloc
in makeStringInfo, makeStringInfoExt, initStringInfo and
initStringInfoExt in the asm codes (see attached stringin
nternal(str, STRINGINFO_DEFAULT_SIZE);
> }
>
> void
> initStringInfoExt(StringInfo str, int initsize)
> {
> initStringInfoInternal(str, initsize);
> }
>
> That's admittedly quite verbose, but it ensures that all of these functi
propose to refactor the function to
mitigate the issue. With attached patch, the large switch case is
moved to a new static function WinGetSlotInFrame().
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
v1-0001-Refactor
Hi David,
Thanks for the review.
> On Sun, 5 Jan 2025 at 21:03, Tatsuo Ishii wrote:
>> Attached is the v2 patch to reflect above.
>
> A quick review.
>
> I don't see any users of STRINGINFO_SMALL_SIZE, so I question the
> value in defining it.
>
> I think
> Hi Gurjeet,
>
> Thanks for looking into my patch.
>
>> On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>>>
>>> Attached is the patch for this.
>>
>> Hi Tatsuo,
>>
>> I believe the newline endings in your patches are causing t
Hi Gurjeet,
Thanks for looking into my patch.
> On Fri, Jan 3, 2025 at 8:54 PM Tatsuo Ishii wrote:
>>
>> Attached is the patch for this.
>
> Hi Tatsuo,
>
> I believe the newline endings in your patches are causing the patch
> application
> to fail. I experie
> If you have trouble convincing people we need this for some new
> reason, then maybe you could review the existing callers to see if
> some of the existing call sites make it any more convincing.
>
> A very quick review, I found:
>
> send_message_to_frontend() initStringInfo(&buf) 1024 is proba
, int initsize);
>>
>
>
> Seems like a good idea.
Thanks.
> Minor nit: the definition of the macro should contain parentheses, like so:
> #define makeStringInfo() ....
Indeed. Thanks for pointing it out.
Attached is the patch for this.
Best reagards,
--
Tatsuo I
nitStringInfoExtended(StringInfo str, int initsize);
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Wed, Dec 25, 2024 at 12:37:04PM +0900, Tatsuo Ishii wrote:
>> Attached is a patch to implement it. In the patch I add two new APIs.
>>
>> extern StringInfo makeStringInfoWithSize(int size);
>> extern void initStringInfoWithSize(StringInfo str, int size);
>>
str, int size);
Maybe I could re-invent the wheel by copying stringinfo.c, but I think
there are some uses cases like me, and it could justify in adding more
code to stringinfo.c.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.c
standby server ...
> """
>
> If we wrote just "collation" here I think it would be less clear,
> because what's the problem is whether the order is different, not
> whether the collation objects are different.
That makes sense. Thanks for the ex
:collation order and character classification,
overriding the setting
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ch for v13! I've now pushed the patches.
Yeah, maybe git apply is not smart enough.
Thank you for pushing the patches!
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
nch-Ensure-previous-progress-message-is-fully-pg13-14.patch
error: patch failed: src/bin/pgbench/pgbench.c:4222
error: src/bin/pgbench/pgbench.c: patch does not apply
So I created a patch for pg13 using patch command. Attached is the
patch for pg13.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
Eng
/Makefile | 6 +++-
> src/Makefile.global.in | 1 +
You don't need to include the patch for configure. Committer will
generate configure when it gets committed. See the discussion:
https://www.postgresql.org/message-id/20241126.102906.1020285543012274306.ishii%40postgresql.org
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Tatsuo Ishii writes:
>> I ran autoconf 2.69 on my Ubuntu 20.04 laptop and got the same diffs
>> plus diffs related runstatedir:
>
>> + --runstatedir=DIR modifiable per-process data [LOCALSTATEDIR/run]
>
>> If my understanding is correct, configure
the git repository has
been generated by autoconf 2.69 too. Maybe autoconf 2.69 generates
slightly different results depending on platform?
So my question is, are there any specific requirements for using
autoconf to generate configure from configure.ac besides the autoconf
version?
Best reagards,
-
Hi Fujii-san,
> On 2024/11/08 11:47, Tatsuo Ishii wrote:
>> I think you need to adjust
>> fprintf(stderr, "%*c\r", chars - 1, ' '); /* Clear the current
>> line */
>> to:
>> fprintf(stderr, "%*c\r", chars, &
> On 2024/11/08 11:47, Tatsuo Ishii wrote:
>> I think you need to adjust
>> fprintf(stderr, "%*c\r", chars - 1, ' '); /* Clear the current
>> line */
>> to:
>> fprintf(stderr, "%*c\r", chars, ' ')
27; '); /* Clear the current
line */
since now chars does not consider the EOL char. By clearing chars - 1,
the closing parenthesis will be left on the screen.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Probably my patch is too invasive and not worth the trouble for the
stable branches. What about back patching your patch to the stable
stable branches, and applying my patch to the master branch?
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
en we would want to
change the log line format in the future. We might introduce this kind
of bug again. By dynamically calculating the number of necessary
spaces, we don't need to think about the concern.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
J
.
The patch works perfectly for the case that there is one extra brace
as shown in your example. However I think it will not work if there
are two or more extra braces.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
there are some non-LATIN1 characters in release-17.sgml,
it will complain like:
iconv: illegal input sequence at position 175
An advantage of this is, we don't need to covert each LATIN1
characters to HTML entities and make the sgml file authors life a
little bit easier.
Best reagards,
--
Ta
e fully supported Unicode, we could
>> ignore all of this.
>
> Patch applied to master --- no new UTF8 restrictions.
I thought the conclusion of the discussion was allowing to use LATIN1
(or UTF-8 encoded LATIN1) characters in SGML files without converting
them to HTML entities. Your patch seems to do opposite.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=641a5b7a1447954076728f259342c2f9201bb0b5
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
gresql.org/docs/current/protocol-message-formats.html
What do you think?
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
s an example, let's say we add a server-side query time to the
> protocol (which honestly seems like a pretty useful feature). So that
> ReadyForQuery now returns the query time if the query_time protocol.
Probaby it's better CommandComplete returns the query time because
there could
> On Wed, 30 Oct 2024 at 07:49, Tatsuo Ishii wrote:
>> > I think one would have to define that somehow. If it's useful, the
>> > additional fields of both extensions could be appended, in some
>> > defined order. But this is an interesting question to thin
e would have to define that somehow. If it's useful, the
> additional fields of both extensions could be appended, in some
> defined order. But this is an interesting question to think about.
I think this kind of extension, which adds new filed to an existing
message type, should be imp
tring
Suppose the X extension wants to extend like this:
Byte1('Z')
Int32
Byte1
Int32
It seems impossible to coexist both.
Does this mean once the wait_for_lsn extension is brought into the
frontend/backend protocol specification, no other extensions that touch
ReadyForQuery cannot be
Hello Alexander,
> Hello Tatsuo-san,
>
> 11.10.2024 07:54, Tatsuo Ishii wrote:
>>>>> ...
>>>>> - number of transactions actually pocessed: 1 (tps = 410.846343)
>>>>> ...
>> Patch pushed.
>
> Please consider fixing a typo s
> On Monday, October 21, 2024, Tatsuo Ishii wrote:
>>
>> I wonder how "PREV(col + 1)" is different from "PREV(col) + 1".
>> Currently my RPR implementation does not allow PREV(col + 1). If
>> "PREV(col + 1)" is different from "PRE
Hi,
I wonder how "PREV(col + 1)" is different from "PREV(col) + 1".
Currently my RPR implementation does not allow PREV(col + 1). If
"PREV(col + 1)" is different from "PREV(col) + 1", it maybe worthwhile
to implement "PREV(col + 1)".
Best re
Hi Amit,
> On Thu, Oct 3, 2024 at 8:53 AM Tatsuo Ishii wrote:
>>
>> > parameter in this case (it is an "optional" parameter, though). However,
>> > when we refer to the stored catalog value, we should call it an option or
>> > a property and callin
ow do you
handle encoding conversion if the "unstructured text file" is encoded
in server side unsafe encoding such as SJIS?
> All characters are taken literally.
> There is no special handling for quotes, backslashes, or escape sequences.
If SJIS text is imported "literally&qu
as the patch is pushed to master branch.
>>>
>>> A small comment on the comments in the patch: pgindent dislikes some
>>> of the comment indentation styles. See attached pgindent.txt. Although
>>> such a small defect would be fixed by committers when a patch gets
>>> committed anyway, you might want to help committers beforehand.
>>
>> Thank you for your comments.
>> I've attached a updated patch that I applied pgindent.
>
> The patch looks good to me. If there's no objection, I will commit and
> push the patch to master branch. I don't think this should be
> back-patched since it modifies the user visible behavior of pgbench.
Patch pushed.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
(double turned comma quotation mark) and U+201D
(double comma quotation mark).
I would like to know why they are necessary too.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> Bruce Momjian writes:
>> Can we use Unicode in the SGML files?
>
> I believe we've been doing it for contributors' names that require
> non-ASCII letters, but not in any other places.
We have non-ASCII letters in charset.sgml too, to show some examples
of collatio
efault they choose to turn it off so turning it back
> on silently - not even documented - is bad.)
+1.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Mon, 7 Oct 2024 15:45:54 -0400
> Bruce Momjian wrote:
>
>> On Mon, Sep 30, 2024 at 11:59:48AM +0200, Daniel Gustafsson wrote:
>> > > On 30 Sep 2024, at 11:03, Tatsuo Ishii wrote:
>> > >
>> > >>>> I think there's an unnec
the patch: pgindent dislikes some
>> of the comment indentation styles. See attached pgindent.txt. Although
>> such a small defect would be fixed by committers when a patch gets
>> committed anyway, you might want to help committers beforehand.
>
> Thank you for your comments.
> I've attached a updated patch that I applied pgindent.
The patch looks good to me. If there's no objection, I will commit and
push the patch to master branch. I don't think this should be
back-patched since it modifies the user visible behavior of pgbench.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Hi Danile, Yugo,
>> On 8 Oct 2024, at 02:03, Tatsuo Ishii wrote:
>>> On Tue, 1 Oct 2024 22:20:55 +0900
>>> Yugo Nagata wrote:
>
>>> I've attached a updated patch.
>>> I added the comment to explain why Perl is used instead of grep or sed.
&
> On Tue, 1 Oct 2024 22:20:55 +0900
> Yugo Nagata wrote:
>
>> On Tue, 1 Oct 2024 15:16:52 +0900
>> Yugo NAGATA wrote:
>>
>> > On Tue, 01 Oct 2024 10:33:50 +0900 (JST)
>> > Tatsuo Ishii wrote:
>> >
>> > > >> That'
> Hi
>
> pá 4. 10. 2024 v 15:16 odesílatel Tatsuo Ishii
> napsal:
>
>> Sorry if this has been discussed before.
>>
>> I wonder why SET ROLE command does not produce a parameter status
>> message noticing the new current_user. Note that SET
>> SESSI
Sorry if this has been discussed before.
I wonder why SET ROLE command does not produce a parameter status
message noticing the new current_user. Note that SET
SESSION_AUTHORIZATION command produces a parameter status message for
the new session_authorization value.
Best reagards,
--
Tatsuo
IMO.
> Or, if it would mean to the failover
> feature rather than the parameter, is it not proper to add tag to
> this
> "failover"?
I don't think so.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
sing "option" there does not seem to be
inconsistent or incorrect. See following example in create
subscription manual:
This clause specifies optional parameters for a subscription.
:
:
connect (boolean)
:
:
Since no connection is made when this option is false, no tables are
subscri
s refereed to.
>
> We could also use "enable the failover parameter". I think both make sense,
> but
> it seems that "failover option" is preferred in the slot_name description.
But a few lines above we have:
This clause specifies optional parame
ched is the patch to do that.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
diff --git a/doc/src/sgml/ref/create_subscription.sgml b/doc/src/sgml/ref/create_subscription.sgml
index 740b7d9421..4eed0f3d0f 100644
--- a/doc/sr
> On Mon, 30 Sep 2024 17:23:24 +0900 (JST)
> Tatsuo Ishii wrote:
>
>> >> I think there's an unnecessary underscore in config.sgml.
>> >> Attached patch fixes it.
>> >
>> > I could not apply the patch with an error.
>> >
>>
better way is use perl itself rather than grep as following.
>
> `perl -ne '/\xC2\xA0/ and print' `
>
> I attached a patch fixed in this way.
GNU sed can also be used without setting LC_ALL:
sed -n /"\xC2\xA0"/p
However I am not sure if non-GNU sed can do this too...
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
ample, locale und-u-kb sorts 'àe' before 'aé'.
>
> This is not non-breaking space, so should not be detected as an error.
That's because non-breaking space (nbsp) is not encoded as 0xa0 in
UTF-8. nbsp in UTF-8 is "0xc2 0xa0" (2 bytes) (A 0xa0 is a nbsp's
ert a non breaking space while editing config.sgml.
However the mistake does not affect the patch.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
You can check it by looking at
line 9383 of config.sgml.
I think it was introduced by 28e858c0f95.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
I think there's an unnecessary underscore in config.sgml.
Attached patch fixes it.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0aec11f443..08173
nterest in
>> having this kind of tool in the tree, I can work on making it
>> reviewable. Either way, I should be able to use it to double-check
>> more complicated test cases.
I definitely am interested in the tool!
>> A while back [2], you were wondering whether our Bison implementation
>> would be able to parse the PATTERN grammar directly. I think this tool
>> proves that the answer is "yes", but PERMUTE in particular causes a
>> shift/reduce conflict. To fix it, I applied the same precedence
>> workaround that we use for CUBE and ROLLUP.
That's a good news!
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> With some bigger partitions, I hit an `ERROR: wrong pos: 1024`. A
> test that reproduces it is attached.
Thanks for the report. Attached is a patch on top of v22 patches to
fix the bug. We keep info in an array
(WindowAggState.reduced_frame_map) to track the rpr pattern match
result status for
h is pushed to master branch.
A small comment on the comments in the patch: pgindent dislikes some
of the comment indentation styles. See attached pgindent.txt. Although
such a small defect would be fixed by committers when a patch gets
committed anyway, you might want to help committers beforehand.
> On Mon, 23 Sept 2024 at 18:28, Tatsuo Ishii wrote:
>> I agree and made necessary changes. See attached v4 patches.
>
> Looks good to me.
Thank you for the review! I have pushed the patch.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en
output.
After thinking more, I lean toward to your opinion. The new tests do
not give big value, but on the other hand they could become a burden
over the years. I do not include the new tests in the v4 patches.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en
- 0 transactions (NaN% of total, tps = 0.00)
SQL script 2: d.sql
- weight: 1 (targets 50.0% of total)
- 0 transactions (NaN% of total, tps = 0.00)
- number of failed transactions: 1 (100.000%)
- number of serialization failures: 1 (100.000%)
- number of deadlock failures: 0 (0.00
age kind difference
in the two tuplestores.
Attached patch fixes 1 & 2.
[1]
https://www.postgresql.org/message-id/CAExHW5vRPRLvsZYLmNGcDLkPDWDHXGSWYjox-to-OsCVFETd3w%40mail.gmail.com
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
>From 814fa7bd
pushed that patch. That should now unblock you on the
> nodeRecursiveunion.c telemetry.
Thanks. Attached is a patch for CTE scan, table function scan and
recursive union scan nodes.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
&
h:
Time: 3.641 ms
Time: 2.356 ms
Time: 2.347 ms
It seems with the patch the performance is slightly better or almost
same. I think the patch improves the performance without sacrificing
the smaller iteration case.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
> On Thu, 19 Sept 2024 at 00:13, Tatsuo Ishii wrote:
>> Actually there's one more executor node type that uses tuplestore:
>> recursive union (used in "with recursive"). The particular node type
>> uses two tuplestore and we cannot simply apply tuplestore_get_
node type
uses two tuplestore and we cannot simply apply tuplestore_get_stats()
to the node type. We need to modify RecursiveUnionState to track the
maximum tuplestore usage. I am not sure this would be worth the
effort. Opinion?
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sra
> On Tue, 17 Sept 2024 at 14:40, Tatsuo Ishii wrote:
>> Attached is the v5 patch. The difference from v4 is addtion of two
>> more tests to explain.sql:
>>
>> 1) spils to disk case
>> 2) splis to disk then switch back to memory case
>
> Looks ok to me,
g < 3
> (as true == 1). So unless PostgreSQL changes the way to sort boolean
> data type, I think the result should be stable.
Attached is the v5 patch. The difference from v4 is addtion of two
more tests to explain.sql:
1) spils to disk case
2) splis to disk then switch back to memory ca
the way to sort boolean
data type, I think the result should be stable.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
a (actual time=0.300..0.633 rows=2
000 loops=1)
Planning Time: 0.069 ms
Execution Time: 474515.476 ms
(8 rows)
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
am I correct?
> Do we want to cover those. This test would be
> the only one where those code paths could be tested.
I am fine to add the first test case.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Right. I will make the change.
> Aside from that, I think the patch is good. Thanks for working on it.
Thanks. Attached is the v4 patch. I am going push it if there's no
objection.
After this, I will work on remaining node types.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: ht
show_storage_info so that the latter can be
used by other node types including window aggregate node. What do you
think?
I also added a test case in explain.sql per discussion with Maxim
Orlov.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http
1 - 100 of 572 matches
Mail list logo
