| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Andres Freund <andres(at)anarazel(dot)de>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem |
| Date: | 2018-02-07 23:45:50 |
| Message-ID: | CAGTBQpZ8MJQA93PDUg2QdXOs_tcDYpiY-fAqcbgRvvjRGdMnZA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 7, 2018 at 7:57 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Claudio Freire wrote:
>
>> - vacuum test on its own parallel group
>
> Hmm, this solution is not very friendly to the goal of reducing test
> runtime, particularly since the new test creates a nontrivial-sized
> table. Maybe we can find a better alternative. Can we use some wait
> logic instead? Maybe something like grab a snapshot of running VXIDs
> and loop waiting until they're all gone before doing the vacuum?
I'm not sure there's any alternative. I did some tests and any active
snapshot on any other table, not necessarily on the one being
vacuumed, distorted the test. And it makes sense, since that snapshot
makes those deleted tuples unvacuumable.
Waiting as you say would be akin to what the patch does by putting
vacuum on its own parallel group.
I'm guessing all tests write something to the database, so all tests
will create a snapshot. Maybe if there were read-only tests, those
might be safe to include in vacuum's parallel group, but otherwise I
don't see any alternative.
> Also, I don't understand why pg_relation_size() is not a better solution
> to determining the table size compared to explain.
I was told pg_relation_size can return stale information. I didn't
check, I took that at face value.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-02-07 23:52:26 | Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem |
| Previous Message | Tom Lane | 2018-02-07 23:01:53 | Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly |