Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgadmin-hackers by date

Next:From: Dave PageDate: 2007-09-26 11:51:21
Subject: Re: A bunch of minor issues
Previous:From: Jyrki WahlstedtDate: 2007-09-26 11:48:20
Subject: Re: A bunch of minor issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group