for your review!
Updated the patch to pass regression tests.
From 90cbddde61c4028a44654005a4e417c74e303d16 Mon Sep 17 00:00:00 2001
From: Atsushi Torikoshi
Date: Mon, 1 Sep 2025 07:35:12 +0900
Subject: [PATCH v2] COPY TO: provide hint when WHERE clause is used
Provide a hint suggesting COPY TO
On Wed, Jul 9, 2025 at 10:09 PM Masahiko Sawada wrote:
> Thank you for reviewing the patches. I've just pushed the fix.
Thanks for pushing them!
Anyway, thanks for the review!
--
Atsushi Torikoshi
after the
> check_stack_depth() call and before the rest of the logic in the
> function. I've attached a sample patch to show what I have in mind.
Thanks for the idea and the sample patch!
Agreed. I’ll go ahead and implement a new patch based on this approach.
--
Atsushi Torikoshi
beta 1, and until the final release.
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
Thanks for your work!
> Add REJECT_LIMIT to control the number of invalid rows COPY IN can ignore
> (Atsushi Torikoshi)
Since REJECT_LIMIT cannot be used with COPY IN
I tried it with JSON
> and it looks fine in the log as well. I can imagine automated
> tools will want to be able to retrieve the plans using the
> structured formats.
I agree that allowing the choice of format would be useful.
However, I believe implementing this would require introducing
at's not clear immediately from the code.
>
>I'm also not convinced that 512 is the blocksize if this logic is
>even correct on every platform. I'm wondering if maybe we should
>simply show the blocks after all.
>
Maybe so. I'll look into this and then decide the unit.
For the other comments, I plan to address them as you suggested.
Regards,
Atsushi Torikoshi
#x27;s one (except DEALLOCATE which is entirely
untracked).
statemets -> statements
statements's -> statements' or statement's?
Regards,
--
Atsushi Torikoshi
On Wed, Apr 8, 2020 at 11:38 PM Julien Rouhaud wrote:
> On Tue, Apr 7, 2020 at 8:40 AM Tatsuro Yamada
> wrot
On Mon, May 25, 2020 at 10:54 AM Atsushi Torikoshi wrote:
> On Thu, May 21, 2020 at 5:10 PM Kyotaro Horiguchi
> wrote:
>
>> Cost numbers would look better if it is cooked a bit. Is it worth
>> being in core?
>
>
> I didn't come up with ideas about how to
On Fri, May 22, 2020 at 11:37 PM Fujii Masao
wrote:
>
>
> On 2020/05/15 9:50, Atsushi Torikoshi wrote:
> > Thanks for reviewing!
> >
> > On Wed, May 13, 2020 at 11:27 PM Fujii Masao <
> masao.fu...@oss.nttdata.com <mailto:masao.fu...@oss.nttdata.com>>
31
>
> Perhaps plan_generation is not needed there.
>
+1.
Now 'calls' is sufficient and 'plan_generation' may confuse users.
BTW, considering 'calls' in pg_stat_statements is the number of times
statements were EXECUTED and 'plans' is the number of t
On Wed, May 20, 2020 at 1:32 PM Kyotaro Horiguchi
wrote:
> At Tue, 19 May 2020 22:56:17 +0900, Atsushi Torikoshi
> wrote in
> > On Sat, May 16, 2020 at 6:01 PM legrand legrand <
> legrand_legr...@hotmail.com>
> > wrote:
> >
> > BTW, I'd also apprecia
t recording the number
of generic and custom plans on pg_stat_statemtents.
Regards,
--
Atsushi Torikoshi
e Portal.
So I'm wondering it's necessary to add a hook to get Portal
or CachedPlanSource.
Are these too much change for getting plan types?
Regards,
--
Atsushi Torikoshi
Thanks for reviewing!
On Wed, May 13, 2020 at 11:27 PM Fujii Masao
wrote:
> What about the attached patch based on yours?
It looks better.
Regards,
--
Atsushi Torikoshi
STATEMENTS-COLUMNS
Regards,
--
Atsushi Torikoshi
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 579ccd34d4..186d1c10ca 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -2706,13 +2706,17 @@ SELECT pid, wait_event_type, wait_
g the case such as only the plan phase has
succeeded and the execution phase has failed, this
presumption can be wrong.
Thoughts?
Regards,
--
Atsushi Torikoshi
On Sat, May 2, 2020 at 11:05 PM Tomas Vondra
wrote
> Pushed. Thanks for the report.
>
Thanks!
--
Atsushi Torikoshi
| 2020-05-01 17:37:02.525006+09
commit_timestamp | 0 |0 | 0 |0 |
0 | 0 | 0 | 2000-01-01 09:00:00+09
(snip)
Attached a patch.
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATION
diff --git a/src/backend/postmaster/pgstat.c b/s
ble to the HEAD.
Regards,
--
Atsushi Torikoshi
On Fri, Feb 28, 2020 at 5:17 PM imai.yoshik...@fujitsu.com <
imai.yoshik...@fujitsu.com> wrote:
> On Wed, Feb 26, 2020 at 1:39 AM, Kyotaro Horiguchi wrote:
> > Hello. I had a brief look on this and have some comments on this.
>
&g
On Mon, Mar 23, 2020 at 1:58 PM Michael Paquier wrote:
> On Thu, Mar 19, 2020 at 12:04:45AM -0300, Alvaro Herrera wrote:
> > None here.
>
> Thanks Álvaro. Applied and back-patched down to 9.5 then.
> --
> Michael
>
Thanks for applying the patch.
Regards,
--
Atsushi Torikoshi
e appropriate name.
>
I've confirmed the patch works as you described above.
And I also poked around it a little bit but found no problems.
Regards,
--
Atsushi Torikoshi
d the patch, I didn't find any problems.
Regards,
--
Atsushi Torikoshi
On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao
wrote:
>
> I meant the following part in the doc.
>
> -
> At startup, the standby begins by restoring all WAL available in the
> archive
> location, calling restore_command. Once it reaches the end of WAL available
> there and restor
On Tue, Mar 17, 2020 at 11:55 AM Fujii Masao
wrote:
> > >Waiting when WAL data is not available from any kind of sources
> > >(local, archive or stream) before trying again to retrieve WAL
> data,
> >
> > I think 'local' means pg_wal here, but the comment on
> > WaitForWALToBecomeAvaila
On Mon, Mar 16, 2020 at 11:32 PM Alvaro Herrera
wrote:
>
> > Should I also change it to "enum"?
>
> Yeah, these were strings until recently (commit 773df883e8f7 Sept 2019).
>
Thanks!
Attached a patch for manuals on create and alter view.
check_option is also described in information_schema.sgm
Thanks for your comments!
On Mon, Mar 16, 2020 at 11:49 AM Fujii Masao
wrote:
> -buffering
> +buffering (string)
>
> Isn't it better to use "enum" rather than "string"?
> In the docs about enum GUC parameters, "enum" is used there.
>
Agreed. I've fixed it to "enum".
But I'm now wonderi
Hi,
The current manual on CREATE TABLE[1] describes storage
parameters with their types.
But manual on CREATE INDEX[2] describes storage parameters
WITHOUT their types.
I think it'll be better to add types to storage parameters
on CREATE INDEX for the consistency.
Attached a patch.
Any thought?
Hi,
As far as I read the reloptions.c, autovacuum_vacuum_cost_delay,
autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor
are the members of relopt_real, so their type seems the same, real.
But the manual about storage parameters[1] says two of their type
are float4 and the other is
Hi,
It seems the comments on SharedHotStandbyActive and
SharedRecoveryInProgress are the same in XLogCtlData.
How about modifying the comment on SharedHotStandbyActive?
Attached a patch.
Regards,
--
Torikoshi Atsushi
fix_comments_on_SharedHotStandbyActive_v1.patch
Description: Binary data
On 2020/02/19 21:46 Fujii Masao :
>> I agree to the former, I think RecoveryWalInterval works well enough.
>RecoveryWalInterval sounds confusing to me...
IMHO as a user, I prefer RecoveryRetrieveRetryInterval because
it's easy to understand this wait_event is related to the
parameter 'wal_retrieve
but won't be allowed to do so by default
> as it won't have EXECUTE privilege on the functions.
>
I see, thanks for your explanation.
--
Regards,
Atsushi Torikoshi
the original
> default role patch or voluntary.
It's not directly related to the patch, but as far as I read the
manual below, I expected pg_write_server_files users could execute
adminpack functions.
| Table 21.1 Default Roles
| pg_write_server_files: Allow writing to files in any location the
database can access on the server with COPY and other file-access functions.
--
Atsushi Torikoshi
33 matches
Mail list logo
