From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Hypothetical indexes using BRIN broken since pg10 |
Date: | 2019-11-19 12:48:59 |
Message-ID: | 20191119124859.GB516103@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 19, 2019 at 08:37:04AM +0100, Julien Rouhaud wrote:
> None from me. I'm obviously biased, but I hope that it can get
> backpatched. BRIN is probably seldom used, but we shouldn't make it
> harder to use it, even if it's that's only for hypothetical usage, and
> even if it'll still be quite inexact.
Re-reading the thread. Any design change should IMO just happen on
master so as we don't take any risks with potential ABI breakages.
Even if there is not much field demand for it, that's not worth the
risk. Thinking harder, I don't actually quite see why it would be an
issue to provide default stats for an hypothetical BRIN index based
using the best estimations we can do down to 10 with the infra in
place. Taking the case of hypopg, one finishes with an annoying
"could not open relation with OID %u", which is not that nice from the
user perspective. Let's wait a bit and see if others have more
arguments to offer.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2019-11-19 13:49:24 | Re: backup manifests |
Previous Message | Juan José Santamaría Flecha | 2019-11-19 12:14:22 | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |