On Tue, Mar 11, 2025 at 5:23 AM Jeff Davis wrote:
>
> On Mon, 2025-03-10 at 17:53 -0400, Tom Lane wrote:
> > I wrote:
> > > I think what is happening is that the patch shut off CREATE
> > > INDEX's update of not only the table's stats but also the
> > > index's stats. This seems unhelpful: the in
On Mon, 2025-03-10 at 17:53 -0400, Tom Lane wrote:
> I wrote:
> > I think what is happening is that the patch shut off CREATE
> > INDEX's update of not only the table's stats but also the
> > index's stats. This seems unhelpful: the index's empty
> > stats can never be what's wanted.
>
> I looked
I wrote:
> I think what is happening is that the patch shut off CREATE
> INDEX's update of not only the table's stats but also the
> index's stats. This seems unhelpful: the index's empty
> stats can never be what's wanted.
I looked at this more closely and realized that it's a simple matter
of h
Jeff Davis writes:
> Sounds good. I will commit something like the v2 patch then soon, and
> if we need a different condition we can change it later.
Sadly, this made things worse not better: crake is failing
cross-version-upgrade tests again [1], with dump diffs like
@@ -270836,8 +270836,8 @@
On Wed, 2025-03-05 at 15:22 +0530, Ashutosh Bapat wrote:
> Hmm. Updating the statistics without consuming more CPU is more
> valuable when autovacuum is off it improves query plans with no extra
> efforts. But if adding a new mode is some significant work, riding it
> on top of autovacuum=off might
On Tue, Mar 4, 2025 at 11:45 PM Jeff Davis wrote:
>
> On Tue, 2025-03-04 at 10:28 +0530, Ashutosh Bapat wrote:
>
> > >
> > > What solution are you suggesting? The only one that comes to mind
> > > is
> > > moving everything to SECTION_POST_DATA, which is possible, but it
> > > seems
> > > like a b
On Tue, 2025-03-04 at 10:28 +0530, Ashutosh Bapat wrote:
> >
> > What solution are you suggesting? The only one that comes to mind
> > is
> > moving everything to SECTION_POST_DATA, which is possible, but it
> > seems
> > like a big design change to satisfy a small detail.
>
> We don't have to d
On Tue, Mar 4, 2025 at 6:25 AM Jeff Davis wrote:
>
> On Mon, 2025-03-03 at 22:04 +0530, Ashutosh Bapat wrote:
> > But while we have hold of reltuples wasting a chance to
> > update it in pg_class does not look right to me.
>
> To me, autovacuum=off is a pretty clear signal that the user doesn't
>
On Mon, 2025-03-03 at 22:04 +0530, Ashutosh Bapat wrote:
> But while we have hold of reltuples wasting a chance to
> update it in pg_class does not look right to me.
To me, autovacuum=off is a pretty clear signal that the user doesn't
want this kind of side-effect to happen. Am I missing something
On Sat, Mar 1, 2025 at 1:40 AM Jeff Davis wrote:
>
> On Fri, 2025-02-28 at 14:51 +0530, Ashutosh Bapat wrote:
> > 2. We aren't restoring the statistics faithfully - as mentioned in
> > Greg's reply. If users dump and restore with autovacuum turned off,
> > they will be surprised to see the statist
On Fri, 2025-02-28 at 14:51 +0530, Ashutosh Bapat wrote:
> 2. We aren't restoring the statistics faithfully - as mentioned in
> Greg's reply. If users dump and restore with autovacuum turned off,
> they will be surprised to see the statistics to be different on the
> original and restored database
Hi Jeff,
I am changing the subject on this email and thus creating a new thread
to discuss this issue.
On Fri, Feb 28, 2025 at 8:02 AM Jeff Davis wrote:
>
> On Tue, 2025-02-25 at 11:11 +0530, Ashutosh Bapat wrote:
> > So the dumped statistics are not restored exactly. The reason for
> > this
> >
12 matches
Mail list logo
