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

From: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: optimized DROP of multiple tables within a transaction
Date: 2012-12-10 05:27:40
Message-ID: CAEZqfEe4GfsOZ1iE_4Jd-8-OpBumAkuB=QeV1xo82Jch9ZRXOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 9, 2012 at 1:07 AM, Tomas Vondra <tv(at)fuzzy(dot)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

Attachment Content-Type Size
drop-in-tx.diff application/octet-stream 2.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2012-12-10 06:03:59 Re: Support for REINDEX CONCURRENTLY
Previous Message Karl O. Pinc 2012-12-10 04:33:59 Re: [PATCH] PL/Python: Add spidata to all spiexceptions