On Mon, Nov 16, 2020 at 11:59:03AM -0300, Álvaro Herrera wrote:
> On 2020-Nov-12, Bruce Momjian wrote:
>
> > For new expression indexes, it is necessary to run > linkend="sql-analyze">ANALYZE or wait for
> > the autovacuum daemon to analyze
> > - the table to generate statistics abo
On 2020-Nov-16, Justin Pryzby wrote:
> I see Alvaro already patched the first issue at bcbd77133.
>
> The problematic language was recently introduced, and I'd reported at:
> https://www.postgresql.org/message-id/20201112211143.GL30691%40telsasoft.com
> And Erik at:
> https://www.postgresql.org/m
On 2020-Nov-12, Bruce Momjian wrote:
> For new expression indexes, it is necessary to run linkend="sql-analyze">ANALYZE or wait for
> the autovacuum daemon to analyze
> - the table to generate statistics about new expression indexes.
> + the table to generate statistics for these
On Thu, Nov 12, 2020 at 06:01:02PM -0500, Bruce Momjian wrote:
> On Thu, Nov 12, 2020 at 03:11:43PM -0600, Justin Pryzby wrote:
> > I guess it should say "The system regularly ..."
> >
> > Also, the last sentence begins "For new expression indexes" and ends with
> > "about new expression indexes",
On Thu, Nov 12, 2020 at 03:11:43PM -0600, Justin Pryzby wrote:
> I guess it should say "The system regularly ..."
>
> Also, the last sentence begins "For new expression indexes" and ends with
> "about new expression indexes", which I guess could instead say "about the
> expressions".
How is this
On Mon, Nov 09, 2020 at 06:27:20PM -0500, Bruce Momjian wrote:
> On Tue, Oct 27, 2020 at 12:12:00AM -0700, Nikolay Samokhvalov wrote:
> > On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello
> > wrote:
> >
> > Would be nice if add some information about it into our docs but not
> > sure
On Mon, Nov 9, 2020 at 08:35:46PM -0300, Fabrízio de Royes Mello wrote:
>
>
> On Mon, 9 Nov 2020 at 20:27 Bruce Momjian wrote:
>
>
> I see REINDEX CONCURRENTLY was fixed in head, but the docs didn't get
> updated to mention the need to run ANALYZE or wait for autovacuum before
> e
On Mon, 9 Nov 2020 at 20:27 Bruce Momjian wrote:
>
> I see REINDEX CONCURRENTLY was fixed in head, but the docs didn't get
> updated to mention the need to run ANALYZE or wait for autovacuum before
> expression indexes can be fully used by the optimizer. Instead of
> putting this mention in the
On Tue, Oct 27, 2020 at 12:12:00AM -0700, Nikolay Samokhvalov wrote:
> On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
> fabriziome...@gmail.com> wrote:
>
> Would be nice if add some information about it into our docs but not sure
> where. I'm thinking about:
> - doc/src/sgml
On Sun, 1 Nov 2020 at 09:29 Michael Paquier wrote:
> On Sun, Nov 01, 2020 at 09:23:44AM +0900, Michael Paquier wrote:
> > By doing so, there is no need to include pg_statistic.h in index.c.
> > Except that, the logic looks fine at quick glance. In the long-term,
> > I also think that it would ma
On Sun, Nov 01, 2020 at 09:23:44AM +0900, Michael Paquier wrote:
> By doing so, there is no need to include pg_statistic.h in index.c.
> Except that, the logic looks fine at quick glance. In the long-term,
> I also think that it would make sense to move both routnes out of
> heap.c into a separate
On Sun, Nov 01, 2020 at 10:11:06AM +0900, Michael Paquier wrote:
> On Fri, Oct 30, 2020 at 10:30:13PM -0500, Justin Pryzby wrote:
> > (I'm quoting from the commit message of the patch I wrote, which is same as
> > your patch).
>
> (I may have missed something, but you did not send a patch, right?)
On Fri, Oct 30, 2020 at 10:30:13PM -0500, Justin Pryzby wrote:
> (I'm quoting from the commit message of the patch I wrote, which is same as
> your patch).
(I may have missed something, but you did not send a patch, right?)
--
Michael
signature.asc
Description: PGP signature
On Sat, Oct 31, 2020 at 07:56:33PM -0300, Fabrízio de Royes Mello wrote:
> Even if we won't use it now, IMHO it is more legible to separate this
> responsibility into its own CopyStatistics function as attached.
By doing so, there is no need to include pg_statistic.h in index.c.
Except that, the l
On Fri, Oct 30, 2020 at 3:22 AM Michael Paquier wrote:
>
> And in spirit, it is possible to address this issue with the patch
> attached which copies the set of stats from the old to the new index.
Did some tests and everything went ok... some comments below!
> For a non-concurrent REINDEX, this
On Fri, Oct 30, 2020 at 03:22:52PM +0900, Michael Paquier wrote:
> On Thu, Oct 29, 2020 at 10:59:52AM +0900, Michael Paquier wrote:
> > REINDEX CONCURRENTLY is by design wanted to provide an experience
> > transparent to the user similar to what a plain REINDEX would do, at
> > least that's the ide
On Thu, Oct 29, 2020 at 10:59:52AM +0900, Michael Paquier wrote:
> REINDEX CONCURRENTLY is by design wanted to provide an experience
> transparent to the user similar to what a plain REINDEX would do, at
> least that's the idea behind it, so.. This qualifies as a bug to me,
> in spirit.
And in sp
On Thu, Oct 29, 2020 at 12:02:11AM +0100, Tomas Vondra wrote:
> On Wed, Oct 28, 2020 at 05:43:08PM -0300, Fabrízio de Royes Mello wrote:
>> 2) REINDEX CONCURRENTLY does not keep statistics (pg_statistc) like a
>> regular REINDEX for indexes using expressions and to me it's a bug. Michael
>> pointed
On Wed, Oct 28, 2020 at 05:43:08PM -0300, Fabrízio de Royes Mello wrote:
On Wed, Oct 28, 2020 at 4:35 PM Tomas Vondra
wrote:
I don't think anyone proposed to do this through autovacuum. There was a
reference to auto-analyze but I think that was meant as 'run analyze
automatically.' Which would
On Wed, Oct 28, 2020 at 4:35 PM Tomas Vondra
wrote:
>
> I don't think anyone proposed to do this through autovacuum. There was a
> reference to auto-analyze but I think that was meant as 'run analyze
> automatically.' Which would work in transactions just fine, I think.
>
Maybe I was not very cle
On Wed, Oct 28, 2020 at 03:18:52PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote:
Given how simple the manual workaround is not having it be manual seems
like it would be safe and straight-forward to implement.
Maybe, but I wou
Tomas Vondra writes:
> On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote:
>> Given how simple the manual workaround is not having it be manual seems
>> like it would be safe and straight-forward to implement.
> Maybe, but I wouldn't be surprised if it was actually a bit trickier i
On Wed, Oct 28, 2020 at 12:05 PM Tom Lane wrote:
> This doesn't seem clearly different from any other situation where
> auto-analyze doesn't react fast enough to suit you.
> I would not
> call it a bug, at least not without a wholesale redefinition of
> how auto-analyze is supposed to work.
On Wed, Oct 28, 2020 at 03:05:39PM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Mon, Oct 26, 2020 at 03:46:10PM -0700, David G. Johnston wrote:
It would seem preferable to call the lack of auto-analyzing after these
operations a bug and back-patch a fix that injects an analyze side-effect
ju
On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote:
On Wed, Oct 28, 2020 at 11:55 AM Tomas Vondra
wrote:
I agree the lack of stats may be quite annoying and cause issues, but my
guess is the chances of backpatching such change are about 0.01%. We
have a usable 'workaround' f
On Mon, Oct 26, 2020 at 9:44 PM Nikolay Samokhvalov
wrote:
> On Mon, Oct 26, 2020 at 7:03 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Monday, October 26, 2020, Nikolay Samokhvalov
>> wrote:
>>>
>>> Although, this triggers a question – should ANALYZE be automated in,
>>> s
Tomas Vondra writes:
> On Mon, Oct 26, 2020 at 03:46:10PM -0700, David G. Johnston wrote:
>> It would seem preferable to call the lack of auto-analyzing after these
>> operations a bug and back-patch a fix that injects an analyze side-effect
>> just before their completion. It doesn't have to be
On Wed, Oct 28, 2020 at 11:55 AM Tomas Vondra
wrote:
> I agree the lack of stats may be quite annoying and cause issues, but my
> guess is the chances of backpatching such change are about 0.01%. We
> have a usable 'workaround' for this - manual analyze.
>
My guess is that it wouldn't be too
On Mon, Oct 26, 2020 at 03:46:10PM -0700, David G. Johnston wrote:
On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
Hi all,
As you all already know Postgres supports functions in index expressions
(marked as immutable ofc) and for this special index the
On Tue, Oct 27, 2020 at 11:06:22AM -0300, Fabrízio de Royes Mello wrote:
On Mon, Oct 26, 2020 at 7:46 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
It would seem preferable to call the lack of auto-analyzing after these
operations a bug and back-patch a fix that injects an analyze
On Wed, Oct 28, 2020 at 2:15 AM Michael Paquier wrote:
>
> On Tue, Oct 27, 2020 at 11:06:22AM -0300, Fabrízio de Royes Mello wrote:
> > When we create a new table or index they will not have statistics until
an
> > ANALYZE happens. This is the default behaviour and I think is not a big
> > problem
On Tue, Oct 27, 2020 at 11:06:22AM -0300, Fabrízio de Royes Mello wrote:
> When we create a new table or index they will not have statistics until an
> ANALYZE happens. This is the default behaviour and I think is not a big
> problem here, but we need to add some note on docs about the need of
> st
On Tue, Oct 27, 2020 at 4:12 AM Nikolay Samokhvalov
wrote:
>
> On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>>
>> Would be nice if add some information about it into our docs but not
sure where. I'm thinking about:
>> - doc/src/sgml/ref/create_index.sgm
On Mon, Oct 26, 2020 at 7:46 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
> It would seem preferable to call the lack of auto-analyzing after these
operations a bug and back-patch a fix that injects an analyze side-effect
just before their completion. It doesn't have to be smart eit
On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> Would be nice if add some information about it into our docs but not sure
> where. I'm thinking about:
> - doc/src/sgml/ref/create_index.sgml
> - doc/src/sgml/maintenance.sgml (routine-reindex)
>
Attaching
On Mon, Oct 26, 2020 at 7:03 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Monday, October 26, 2020, Nikolay Samokhvalov
> wrote:
>>
>> Although, this triggers a question – should ANALYZE be automated in, say,
>> pg_restore as well?
>>
>
> Independent concern.
>
It's the same cl
On Monday, October 26, 2020, Nikolay Samokhvalov
wrote:
>
>
> Although, this triggers a question – should ANALYZE be automated in, say,
> pg_restore as well?
>
Independent concern.
>
> And another question: how ANALYZE needs to be run? If it's under the
> user's control, there is an option to u
On Mon, Oct 26, 2020 at 3:46 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> It would seem preferable to call the lack of auto-analyzing after these
> operations a bug and back-patch a fix that injects an analyze side-effect
> just before their completion. It doesn't have to be smart
On Mon, Oct 26, 2020 at 3:08 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
> Hi all,
>
> As you all already know Postgres supports functions in index expressions
> (marked as immutable ofc) and for this special index the ANALYZE command
> creates some statistics (new pg_statistic en
39 matches
Mail list logo
