From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PATCH: optimized DROP of multiple tables within a transaction |
Date: | 2013-01-07 22:08:31 |
Message-ID: | 50EB475F.800@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7.1.2013 10:07, Shigeru Hanada wrote:
> Hi Tomas,
>
> I reviewed v6 patch, and found that several places need fix.
> Sorry for extra nitpickings.
>
> * I found another extra space after asterisk.
>
> + RelFileNode * nodes;
Thanks, fixed.
>
> * Curly bracket which starts code block should be at the head of next line.
>
> + /* extend the array if needed (double the size) */
> + if (maxrels <= nrels) {
Fixed.
>
> * There are several trailing tabs in src/backend/catalog/storage.c.
Fixed (I balieve).
> * naming of DROP_RELATIONS_BSEARCH_LIMIT (or off-by-one bug?)
> IIUC bsearch is used when # of relations to be dropped is *more* than
> the value of DROP_RELATIONS_BSEARCH_LIMIT (10). IMO this behavior is
> not what the macro name implies; I thought that bsearch is used for 10
> relations. Besides, the word "LIMIT" is used as *upper limit* in
> other macros. How about MIN_DROP_REL[ATION]S_BSEARCH or
> DROP_REL[ATION]S_LINEAR_SEARCH_LIMIT?
> # using RELS instead of RELATIONS would be better to shorten the name
>
I've changed the name to DROP_RELS_BSEARCH_THRESHOLD. I believe this
naming is consistent with options like "geqo_threshold" - when the
number of relations reaches the specified value, the bsearch is used.
I've also increased the value from 10 to 20, in accordance with the
previous discussion.
>
> * +1 for Alvaro's suggestion about avoiding palloc traffic by starting
> with 8 elements or so.
>
Done.
regards
Tomas
Attachment | Content-Type | Size |
---|---|---|
drop-in-transaction-v7.patch | text/x-diff | 8.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-01-07 22:14:43 | Re: psql \l to accept patterns |
Previous Message | Robert Haas | 2013-01-07 22:00:39 | Re: Improve compression speeds in pg_lzcompress.c |