Re: State of Beta 2
От | Andrew Rawnsley |
---|---|
Тема | Re: State of Beta 2 |
Дата | |
Msg-id | DDA7A9F8-E538-11D7-BA76-000393A47FCC@ravensfield.com обсуждение исходный текст |
Ответ на | Re: State of Beta 2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: State of Beta 2
|
Список | 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@aon.at> writes: >> On Thu, 11 Sep 2003 00:25:53 -0400, Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-general по дате отправления: