Re: Pet Peeves? - Mailing list pgsql-general

PROCEDUREs *which compile into Procedure Cache* and have IN/OUT (Mode) parameters..

Martin Gainty
______________________________________________
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission.




> Date: Fri, 30 Jan 2009 12:37:11 +0900
> From: craig@postnewspapers.com.au
> To: stark@enterprisedb.com
> CC: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Pet Peeves?
>
> Gregory Stark wrote:
>
> > So, what do people say? Is Postgres perfect in your world or does it do some
> > things which rub you the wrong way?
>
> The few things that used to really bug me have gone away between 8.1 and
> 8.3. The big one is that there are no longer issues with temp tables in
> PL/PgSQL functions or any of the other problems related to the lack of
> automatic plan invalidation for functions.
>
> I could go on forever about the things I LIKE about Pg.
>
>
> There are a few niggles I have noticed, though:
>
> - VACUUM FULL is rather slow and often leaves indexes badly bloated.
> This is a usability issue for new admins, too, who won't know they're
> usually better off using CLUSTER. That in its self suggests something's
> not right, IMO.
>
> - There's no REINDEX CONCURRENTLY.
>
> - There are no built-in ways for admins to easily discover, be alerted
> to, or manually check for index and table bloat. We NEED a
> pg_catalog.pg_bloat view IMO, as well as NOTICE level warnings from
> VACUUM when very bloated indexes and tables are discovered. This is a
> mainly a usability issue for new admins.
>
> - Bytea's literal format is wasteful and is painful to work with.
> Supporting something reasonably compact and commonly understood by most
> tools and libraries (like, say, base64) would be really nice. It'd also
> be useful for backup/restore.
>
> - The problems involved in restoring/upgrading a database to a newer
> major version when extensions like PostGIS are in use. Argh.
>
> - Table partitioning is effective, but somewhat clumsy, and would really
> benefit from some automatic management tools.
>
> - No column-level triggers and, thus, no way to attach a trigger to a
> domain type.
>
> - The need for a dump and restore for major version upgrades. I
> understand why, but ...
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

---

Windows Live™ Hotmail®:…more than just e-mail. Check it out.