Re: State of Beta 2

From: Andrew Rawnsley <ronz(at)ravensfield(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: State of Beta 2
Date: 2003-09-12 15:50:43
Message-ID: DDA7A9F8-E538-11D7-BA76-000393A47FCC@ravensfield.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Small soapbox moment here...

ANYTHING that can be done to eliminate having to do an initdb on
version changes would make a lot of people do cartwheels. 'Do a
dump/reload' sometimes comes across a bit casually on the lists (my
apologies if it isn't meant to be), but it can be be incredibly onerous
to do on a large production system. That's probably why you run across
people running stupid-old versions.

I am, of course, speaking from near-complete ignorance about what it
takes to avoid the whole problem.

On Friday, September 12, 2003, at 10:37 AM, Tom Lane wrote:

> Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
>> On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> wrote:
>>> "int8col = 42" isn't indexable. [...] --- maybe
>>> just taking out the int8-vs-int4 comparison operators would improve
>>> matters. I might be willing to advocate another initdb to do that,
>
>> You mean
>> DELETE FROM pg_operator WHERE oid in (15, 36, 416, 417);
>> and possibly some more oids? Does this really require an initdb?
>
> I think so. Consider for instance stored views that contain references
> to those operators. In any case, I don't really want to have to ask
> people who complain about 7.4 performance problems whether they've done
> the above.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--------------------

Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message scott.marlowe 2003-09-12 15:59:59 Re: Function to convert
Previous Message Christopher Browne 2003-09-12 15:24:41 Re: best arrangement of 3 disks for (insert) performance