Re: PATCH: optimized DROP of multiple tables within a transaction

Shigeru Hanada <shigeru.hanada@gmail.com>

From: Shigeru Hanada <shigeru.hanada@gmail.com>
To: Tomas Vondra <tv@fuzzy.cz>
Cc: pgsql-hackers@postgresql.org
Date: 2012-12-10T05:27:40Z
Lists: pgsql-hackers

Attachments

On Sun, Dec 9, 2012 at 1:07 AM, Tomas Vondra <tv@fuzzy.cz> wrote:
> * If you're dropping a single table, it really does not matter - the
>   difference will be like 100 ms vs. 200 ms or something like that.

Did you try dropping 10,000 tables in 100 batches, as same as previous post?
If so the overhead introduced by the patch is only 1.52ms per table.
It seems acceptable to me.

> So I'd vote to ditch that special case optimization.

+1.  It seems very difficult to determine reasonable threshold of such
kind of optimization.  As described above, the overhead seems enough
little, so using bsearch in any case seems fine.

Besides, v3.2 patch needs some more fixes, for minor issues.

* Opening curly bracket of if/for/while/etc. should be in the next
line, like this:
    if (foo == bar) /* { <= not here */
    {
        ...
    }
* Use hard-tab instead of white-spaces to indent variable name in declarations.
  For these two issues, please see the page below:
  http://www.postgresql.org/docs/9.2/static/source-format.html

* PostgreSQL allows C89 features, so we can't use variable length array.
* Contains unintentional blank lines?

Please see attached patch for details of fixes above.

-- 
Shigeru HANADA

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Accelerate end-of-transaction dropping of relations