Обсуждение: pgsql: Introduce bloom_filter_size for BRIN bloom opclass
Introduce bloom_filter_size for BRIN bloom opclass Move the calculation of Bloom filter parameters (for BRIN indexes) into a separate function to make reuse easier. At the moment we only call it from one place, but that may change and it's easier to read anyway. Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/0e1f3350-c9cf-ab62-43a5-5dae314de89c%40enterprisedb.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/2b8b2852bbc54f02e26131a966e62c432144dc93 Modified Files -------------- src/backend/access/brin/brin_bloom.c | 63 +++++++++++++++++++++++++++--------- 1 file changed, 47 insertions(+), 16 deletions(-)
On Sun, Jul 02, 2023 at 08:25:34AM +0000, Tomas Vondra wrote: > Introduce bloom_filter_size for BRIN bloom opclass > > Move the calculation of Bloom filter parameters (for BRIN indexes) into > a separate function to make reuse easier. At the moment we only call it > from one place, but that may change and it's easier to read anyway. > > Reviewed-by: Heikki Linnakangas > Discussion: https://postgr.es/m/0e1f3350-c9cf-ab62-43a5-5dae314de89c%40enterprisedb.com koel has failed its indent step after these commits. I am unsure whether you need to fix this as it does not seem that we have a consensus to automate that, just FYI. -- Michael
Вложения
Michael Paquier <michael@paquier.xyz> writes:
> koel has failed its indent step after these commits. I am unsure
> whether you need to fix this as it does not seem that we have a
> consensus to automate that, just FYI.
Well, *somebody* has to fix it, otherwise why did we set up the animal?
But the impression I had was that a majority of committers want to
start keeping the tree pgindent-clean.
regards, tom lane
On 2023-07-02 Su 20:30, Tom Lane wrote:
Michael Paquier <michael@paquier.xyz> writes:koel has failed its indent step after these commits. I am unsure whether you need to fix this as it does not seem that we have a consensus to automate that, just FYI.Well, *somebody* has to fix it, otherwise why did we set up the animal? But the impression I had was that a majority of committers want to start keeping the tree pgindent-clean.
I think we need to spell out expectations more clearly. Here's what I said to Tomas in a private message:
I think the expectation is that, while there might be cases where you want to make some commits and then indent afterwards, so the changes are clear, for most cases you should try to commit pre-indented patches.
But that's just my opinion. I think we need to spell it out more formally.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
On 7/3/23 04:18, Andrew Dunstan wrote: > > On 2023-07-02 Su 20:30, Tom Lane wrote: >> Michael Paquier <michael@paquier.xyz> writes: >>> koel has failed its indent step after these commits. I am unsure >>> whether you need to fix this as it does not seem that we have a >>> consensus to automate that, just FYI. >> Well, *somebody* has to fix it, otherwise why did we set up the animal? >> But the impression I had was that a majority of committers want to >> start keeping the tree pgindent-clean. >> >> > > > I think we need to spell out expectations more clearly. Here's what I > said to Tomas in a private message: > > I think the expectation is that, while there might be cases where > you want to make some commits and then indent afterwards, so the > changes are clear, for most cases you should try to commit > pre-indented patches. > > But that's just my opinion. I think we need to spell it out more formally. > I've pushed a fix for the indentation issues caused by my commits (this one and the commit touching trigger.c). But I agree with Andrew it'd be good to spell out the expectations - perhaps it's spelled out somewhere deep in the pgindent, not sure. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company