From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: PANIC: invalid index offnum: 186 when processing BRIN indexes in VACUUM |
Date: | 2017-11-02 21:29:30 |
Message-ID: | 14232.1509658170@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Tom Lane wrote:
>> So what would happen if we just don't summarize partial ranges?
> Index scan would always have to read all the heap pages for that partial
> range. Maybe not a big issue, but when you finish loading a table, it'd
> be good to have a mechanism to summarize that partial range ...
I guess if the ranges are big this might not be nice.
> Rather than remove the capability, I'd be inclined to make
> brin_summarize_new_values summarize the final partial range, and have
> VACUUM not do it. Would that be too inconsistent?
That doesn't really get you out of the problem that this is an abuse of
the relation extension lock, and is likely to cause issues when people
try to optimize that locking mechanism.
Why is it that the regular technique doesn't work, ie create a placeholder
tuple and let it get added to by any insertions that happen?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Piotr Stefaniak | 2017-11-02 21:32:51 | Re: SQL/JSON in PostgreSQL |
Previous Message | Tom Lane | 2017-11-02 21:24:59 | Re: Setting pd_lower in GIN metapage |