On Mon, 23 Sept 2024 at 22:04, David Rowley wrote:
> Can you have a look at the attached and let me know if it's easier to
> understand now?
Pushed.
David
On Mon, Sep 23, 2024 at 7:53 PM David Rowley wrote:
>
> On Mon, 23 Sept 2024 at 23:23, jian he wrote:
> > looks fine. but maybe we can add the following information
> > "if The ONLY is specified, the second set of
> > statistics won't include each children individual statistics"
> > I think that'
On Mon, 23 Sept 2024 at 23:23, jian he wrote:
> looks fine. but maybe we can add the following information
> "if The ONLY is specified, the second set of
> statistics won't include each children individual statistics"
> I think that's the main difference between specifying ONLY or not?
Ok, I thin
On Mon, Sep 23, 2024 at 6:04 PM David Rowley wrote:
>
>
> If this is confusing, I think there's a bunch of detail that I tried
> to keep that's just not that useful. The part about analyzing
> partitions just once and the part about not collecting non-inheritance
> stats for the partitioned table
On Mon, 23 Sept 2024 at 19:39, jian he wrote:
> sql-analyze.html
> For partitioned tables, ANALYZE gathers statistics by sampling rows
> from all partitions. Each leaf partition is also recursively analyzed
> and the statistics updated. This recursive part may be disabled by
> using the ONLY keywo
On Mon, Sep 23, 2024 at 12:46 PM David Rowley wrote:
>
> On Mon, 23 Sept 2024 at 15:29, jian he wrote:
> > Given the above context, I am still confused with this sentence in
> > sql-analyze.html.
> > "If ONLY is specified before the table name, only that table is analyzed."
> >
> > like in the ab
On Mon, 23 Sept 2024 at 15:29, jian he wrote:
> Given the above context, I am still confused with this sentence in
> sql-analyze.html.
> "If ONLY is specified before the table name, only that table is analyzed."
>
> like in the above sql example, only_inh_parent's child is also being analyzed.
I
On Sun, Sep 22, 2024 at 9:09 PM David Rowley wrote:
>
> v7-0002 is all my changes.
>
> I'd like to push this soon, so if anyone has any last-minute feedback,
> please let me know in the next few days.
>
drop table if exists only_inh_parent,only_inh_child;
CREATE TABLE only_inh_parent (a int , b
On Sun, 22 Sept 2024 at 23:09, David Rowley wrote:
> I'd like to push this soon, so if anyone has any last-minute feedback,
> please let me know in the next few days.
Many thanks for your updates and assistance.
Looks good. Agreed, I was probably too conservative in some of the
doc updates.
Tha
On Fri, 20 Sept 2024 at 13:20, Michael Harris wrote:
> I have attached a new version of the patch with this feedback incorporated.
I looked over the v6 patch and I don't have any complaints. However, I
did make some minor adjustments:
* A few places said things like "and possibly partitions and/
Thanks for the feedback, and sorry it has taken a few days to respond.
On Mon, 16 Sept 2024 at 12:29, jian he wrote:
> in https://www.postgresql.org/docs/current/ddl-inherit.html
> <<<
> Commands that do database maintenance and tuning (e.g., REINDEX,
> VACUUM) typically only work on individual,
hi.
in https://www.postgresql.org/docs/current/ddl-inherit.html
<<<
Commands that do database maintenance and tuning (e.g., REINDEX,
VACUUM) typically only work on individual, physical tables and do not
support recursing over inheritance hierarchies. The respective
behavior of each individual comm
On 2024-09-11 16:47, Michael Harris wrote:
Thanks for the feedback.
On Tue, 10 Sept 2024 at 22:03, torikoshia
wrote:
Regarding the addition of partition descendant tables, should we also
update the below comment on expand_vacuum_rel? Currently it refers
only
partitions:
| * Given a Vacuum
Thanks for the feedback.
On Tue, 10 Sept 2024 at 22:03, torikoshia wrote:
> Regarding the addition of partition descendant tables, should we also
> update the below comment on expand_vacuum_rel? Currently it refers only
> partitions:
>
> | * Given a VacuumRelation, fill in the table OID if it wa
On 2024-09-09 16:56, Michael Harris wrote:
Thanks for updating the patch.
Here is a minor comment.
@@ -944,20 +948,32 @@ expand_vacuum_rel(VacuumRelation *vrel,
MemoryContext vac_context,
MemoryContextSwitchTo(oldcontext);
}
..
+* Unless the user has specified ONLY,
Thanks for the feedback David.
On Mon, 9 Sept 2024 at 11:27, David Rowley wrote:
> You've written "was" (past tense), but then the existing text uses
> "will" (future tense). I guess if the point in time is after parse and
> before work has been done, then that's correct, but I think using "is"
>
On Sun, 1 Sept 2024 at 13:32, Michael Harris wrote:
> v3 of the patch is attached, and I will submit it to the commitfest.
I think this patch is pretty good.
I only have a few things I'd point out:
1. The change to ddl.sgml, technically you're removing the caveat, but
I think the choice you've
On 2024-09-01 10:31, Michael Harris wrote:
Hello Atsushi & Melih
Thank you both for your further feedback.
On Thu, 29 Aug 2024 at 21:31, Melih Mutlu
wrote:
I believe moving "[ ONLY ]" to the definitions of table_and_columns
below, as you did with "[ * ]", might be better to be consistent wit
On Sun, 1 Sept 2024 at 13:41, Michael Harris wrote:
> https://commitfest.postgresql.org/49/5226/
>
> I was not sure what to put for some of the fields - for 'reviewer' should
> I have put the people who have provided feedback on this thread?
I think it's fairly common that only reviewers either
Thanks David
I had not read that wiki page well enough, so many thanks for alerting
me that I had to create a commitfest entry. I already had a community
account so I was able to login and create it here:
https://commitfest.postgresql.org/49/5226/
I was not sure what to put for some of the fie
Hello Atsushi & Melih
Thank you both for your further feedback.
On Thu, 29 Aug 2024 at 21:31, Melih Mutlu wrote:
> I believe moving "[ ONLY ]" to the definitions of table_and_columns below, as
> you did with "[ * ]", might be better to be consistent with other places (see
> [1])
Agreed. I hav
Hi Michael,
On Fri, 23 Aug 2024 at 22:01, Michael Harris wrote:
> V2 of the patch is attached.
(I understand this is your first PostgreSQL patch)
I just wanted to make sure you knew about the commitfest cycle we use
for the development of PostgreSQL. If you've not got one already, can
you regi
On Thu, Aug 29, 2024 at 7:31 PM Melih Mutlu wrote:
>
> Hi Michael,
>
> Michael Harris , 23 Ağu 2024 Cum, 13:01 tarihinde şunu
> yazdı:
>>
>> V2 of the patch is attached.
>
>
> Thanks for updating the patch. I have a few more minor feedbacks.
>
>> -ANALYZE [ ( option [, ...] ) ]
>> [ table_and_co
Hi Michael,
On 2024-08-23 19:01, Michael Harris wrote:
V2 of the patch is attached.
Thanks for the proposal and the patch.
You said this patch was a first draft version, so these may be too minor
comments, but I will share them:
-- https://www.postgresql.org/docs/devel/progress-reporting
Hi Michael,
Michael Harris , 23 Ağu 2024 Cum, 13:01 tarihinde şunu
yazdı:
> V2 of the patch is attached.
>
Thanks for updating the patch. I have a few more minor feedbacks.
-ANALYZE [ ( option [, ...] )
> ] [ table_and_columns [, ...] ]
> +ANALYZE [ ( option [, ...] )
> ] [ [ ONLY ] table_and_c
Thanks for the feedback Melih,
On Thu, 22 Aug 2024 at 21:26, Melih Mutlu wrote:
> It seems like extended_relation_expr allows "tablename *" syntax too. That
> should be added in docs as well. (Same for VACUUM doc)
I had included it in the parameter description but had missed it from
the synopsi
Hi Michael,
Thanks for the patch.
I quickly tried running some ANALYZE ONLY queries, it seems like it works
fine.
-ANALYZE [ ( option [, ...] )
> ] [ table_and_columns [, ...] ]
> +ANALYZE [ ( option [, ...] )
> ] [ [ ONLY ] table_and_columns
> [, ...] ]
It seems like extended_relation_expr all
Hi All,
Here is a first draft of a patch to implement the ONLY option for
VACUUM and ANALYZE.
I'm a little nervous about the implications of changing the behaviour of VACUUM
for inheritance structures; I can imagine people having regularly
executed scripts
that currently vacuum all the tables in
On Thu, 22 Aug 2024 at 13:38, Michael Harris wrote:
> Would we want to apply that change to VACUUM too? That might be a
> bit drastic, especially if you had a multi-level inheritance structure
> featuring
> large tables.
I think they'd need to work the same way as for "VACUUM (ANALYZE)", it
woul
Tom Lane wrote:
> Yeah, my thought was to change the behavior so it's consistent in
> that case too. This doesn't seem to me like a change that'd
> really cause anybody serious problems: ANALYZE without ONLY would
> do more than before, but it's work you probably want done anyway.
Would we want
David Rowley writes:
> I feel like we might need to either bite the bullet and make ONLY work
> consistently with both, or think of another way to have ANALYZE not
> recursively gather stats for each partition on partitioned tables.
> Could we possibly get away with changing inheritance parent beh
On Thu, 22 Aug 2024 at 11:32, Michael Harris wrote:
> One other thing I noticed when reading the code. The function
> expand_vacuum_rel in vacuum.c seems to be responsible for adding the
> partitions. If I am reading it correctly, it only adds child tables in
> the case of a partitioned table, not
Thank you all for the replies & discussion.
It sounds like more are in favour of using the ONLY syntax attached to
the tables is the best way to go, with the main advantages being:
- consistency with other commands
- flexibility in allowing to specify whether to include partitions
for individual
David Rowley , 21 Ağu 2024 Çar, 01:53 tarihinde şunu
yazdı:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> > I like trying to use ONLY somehow.
>
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
>
> Making
On Tue, Aug 20, 2024 at 6:53 PM David Rowley wrote:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> > I like trying to use ONLY somehow.
>
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
The table modifier
David Rowley writes:
> On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
>> I like trying to use ONLY somehow.
> Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
> or as a table modifier like gram.y's extended_relation_expr?
> Making it a command option means that the option
On Wed, 21 Aug 2024 at 06:41, Robert Haas wrote:
> I like trying to use ONLY somehow.
Do you mean as an ANALYZE command option, i.e. ANALYZE (only) table;
or as a table modifier like gram.y's extended_relation_expr?
Making it a command option means that the option would apply to all
tables liste
On Tue, Aug 20, 2024 at 1:52 AM Michael Harris wrote:
> 2. The existing ANALYZE command has the following structure:
>
> ANALYZE [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
>
> It would be easiest to add ONLY as another option, but that
> doesn't look quite
> right to me
Melih Mutlu , 20 Ağu 2024 Sal, 19:26 tarihinde şunu
yazdı:
> Hi Michael,
>
> Thanks for starting this thread. I've also spent a bit time on this after
> reading your first thread on this issue [1]
>
Forgot to add the reference [1]
[1]
https://www.postgresql.org/message-id/cadofcaxvbd0ygp_eac9chmz
Hi Michael,
Thanks for starting this thread. I've also spent a bit time on this after
reading your first thread on this issue [1]
Michael Harris , 20 Ağu 2024 Sal, 08:52 tarihinde şunu
yazdı:
> The problem is that giving an ANALYZE command targeting a partitioned table
> causes it to update stat
On Tue, 20 Aug 2024 at 23:25, Ilia Evdokimov
wrote:
> Your proposal is indeed interesting, but I have a question: can't your issue
> be resolved by properly configuring autovacuum instead of developing a new
> feature for ANALYZE?
Basically, no. There's a "tip" in [1] which provides information
On 20.8.24 10:42, Jelte Fennema-Nio wrote:
On Tue, 20 Aug 2024 at 07:52, Michael Harris wrote:
1. Would such a feature be welcomed? Are there any traps I might not
have thought of?
I think this sounds like a reasonable feature.
2. The existing ANALYZE command has the following struct
On Tue, 20 Aug 2024 at 07:52, Michael Harris wrote:
> 1. Would such a feature be welcomed? Are there any traps I might not
> have thought of?
I think this sounds like a reasonable feature.
> 2. The existing ANALYZE command has the following structure:
>
> ANALYZE [ ( option [, ...] ) ]
43 matches
Mail list logo
