Re: A bunch of minor issues

From: Dave Page <dpage(at)postgresql(dot)org>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: pgadmin-hackers(at)postgresql(dot)org, Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Subject: Re: A bunch of minor issues
Date: 2007-09-26 11:49:05
Message-ID: 46FA4731.9060506@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Heikki Linnakangas wrote:
>> RECREATE is a pgAdmin extension that drops and recreates an index.
>
> What's the advantage of that, compared to normal REINDEX?

Quoth the PG docs:

REINDEX is similar to a drop and recreate of the index in that the index
contents are rebuilt from scratch. However, the locking considerations
are rather different. REINDEX locks out writes but not reads of the
index's parent table. It also takes an exclusive lock on the specific
index being processed, which will block reads that attempt to use that
index. In contrast, DROP INDEX momentarily takes exclusive lock on the
parent table, blocking both writes and reads. The subsequent CREATE
INDEX locks out writes but not reads; since the index is not there, no
read will attempt to use it, meaning that there will be no blocking but
reads may be forced into expensive sequential scans. Another important
point is that the drop/create approach invalidates any cached query
plans that use the index, while REINDEX does not.

>> It
>> isn't implemented for constraints (iirc) due to the window in which it
>> could leave the table unconstrained. Although... is that actually an
>> issue? I assume it is because the catalogs are always read with
>> SnapshotNow() (is that the right one?). Anyway, you get the point.
>> Grateful if you can confirm if we're right to worry or not!
>
> I think it would work if you dropped and recreated the constraint in a
> single transaction. The DROP would acquire an exclusive lock on the
> table, so anyone trying to insert to it would block.

OK.

> Finnish texts do tend to more longer than English. It's not a problem in
> most places, but for example "Rename" in the favourites manager is
> translated to "Nimeä uudelleen", which is quite a bit longer. If we just
> made the space reserved for the button bigger, it would look quite silly
> in English I think. But as it is, the button is partly underneath the
> "Remove" button.

Wow, that is longer. I think we normally suggest leaving 50% extra space
over the English text. I'm not sure how we'd handle that case
automatically unless we rewrite everything to use sizers (which are a
lot more usable now than when most of the dialogues were first written).
Thats a *lot* of work though.

> Only somewhat ;-). I hacked wxXml, wxrc and stringextract to do that.
> I'll clean that up and post patches to wx the wxWidgets list, as well
> the changes to stringextract.

Cool, thanks.

> Meanwhile, anyone interested in the pgadmin3.pot file I have here with
> the file/line numbers in it? I can post it if so..

I'd be more interested in the patches so I can update my utilities and
those of developer.pgadmin.org where stringextract tends to be run (I
imagine Guillaume would like a copy too).

>>> In the "Manage macros" dialog, the "Name" column in the list is way too
>>> narrow, about 2-3 chars.
>> That must be a GTK thing as it's about 2.5 times the size of the Key
>> column here. Is the Key column too large, forcing the Name to be small,
>> or is there a bunch of unused space?
>
> There's a bunch of unused space. I can send you a screenshot.

I'll be in the office tomorrow - I can test it properly on Linux then
and eyeball your screen.

Thanks, Dave

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2007-09-26 11:51:21 Re: A bunch of minor issues
Previous Message Jyrki Wahlstedt 2007-09-26 11:48:20 Re: A bunch of minor issues