From: | Melvin Davidson <melvin6925(at)gmail(dot)com> |
---|---|
To: | Martín Marqués <martin(at)2ndquadrant(dot)com> |
Cc: | Scott Mead <scottm(at)openscg(dot)com>, Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>, Job <Job(at)colliniconsulting(dot)it>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: R: Vacuum full: alternatives? |
Date: | 2016-06-20 15:25:49 |
Message-ID: | CANu8Fiz=r73qximt7hoBoQqex6c3Owv5Zx=UGqPkFZFmbMMT2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Jun 20, 2016 at 11:18 AM, Martín Marqués <martin(at)2ndquadrant(dot)com>
wrote:
> El 20/06/16 a las 12:06, Melvin Davidson escribió:
> >
> > Martin and Vik,
> >
> >>...Think about a SELECT which has to scan all child tables.
> >
> > You are really digging for a corner case.
> > If a scan has to scan all child tables, then
> > A. it negates the ability to make partitions which are not used
> > and
> > B. The SELECT query is poorly crafted.
>
> And you haven't read Vik's reply. :)
>
> --
> Martín Marqués http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>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 have proposed a reasonable solution to solve the problem in it's
entirety. Do you have a better one?
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
From | Date | Subject | |
---|---|---|---|
Next Message | Martín Marqués | 2016-06-20 15:33:50 | Re: R: Vacuum full: alternatives? |
Previous Message | Martín Marqués | 2016-06-20 15:18:58 | Re: R: Vacuum full: alternatives? |