Re: R: Vacuum full: alternatives?

On Mon, Jun 20, 2016 at 1:53 PM, Vik Fearing <vik(at)2ndquadrant(dot)fr> wrote:

> On 20/06/16 17:25, Melvin Davidson wrote:
> >>And you haven't read Vik's reply. :)
> >
> > Yes I have. Vacuum wll not lock all tables at once, only the ones it is
> > currently working on, so the planner may have a slight delay,
> > but it will not be gigantic.
>
> I think you should try it.
>
> > I have proposed a reasonable solution to solve the problem in it's
> > entirety. Do you have a better one?
>
> You mean by partitioning? That doesn't really solve any problem, except
> that vacfull-ing a partition should be faster than doing the whole
> enchilada.
> --
> Vik Fearing +33 6 46 75 15 36
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
>

Vik,
Your comments make no sense to me.

>Or any SELECT on the parent at all. The planner needs to examine the
>CHECK constraints on the children and can't do it if the child is locked
>in ACCESS EXCLUSIVE mode.

Nowhere in the documentation does it say that the planner needs to take
locks
or is even concerned with them. Locks are transient, so they do not figure
into
the query plan. If I am wrong, kindly point me to the documentation or url
that
shows contrary.

>I think you should try it.

Why would I even attempt that? We do not know the PostgreSQL version or O/S
as yet.
I do not have any info regarding table structure or any data. I have given
a suggestion
that will probably help solve the problem. I am not here to do any actual
work.

>That doesn't really solve any problem, except
>that vacfull-ing a partition should be faster than doing the whole
>enchilada.

That is exactly the point, because based on the original problem
description, the
data is transient.

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.