Re: [pgsql-www] [PERFORM] Help speeding up delete

2005-11-17 Thread Magnus Hagander
> >>That way if someone wanted to upgrade from 7.2 to 8.1, they 
> can just 
> >>grab the latest dumper from the website, dump their old 
> database, then 
> >>upgrade easily.
> > 
> > But if they're upgrading to 8.1, don't they already have the new 
> > pg_dump? How else are they going to dump their *new* database?
> 
> Erm.  Usually when you install the new package/port for 8.1, 
> you cannot have both new and old installed at the same time 
> man.  Remember they both store exactly the same binary files 
> in exactly the same place.

Urrk. Didn't think of that. I always install from source on Unix, which
doesn't have the problem. And the Windows port doesn't have this problem
- it will put the binaries in a version dependant directory.

One could claim the packages are broken ;-), but that's not gonig to
help here, I know...

(I always install in pgsql-, and then symlink pgsql there..)


> >>etc.  (Seriously.) In fact, few realise at all that they should use 
> >>the 8.1 dumper.
> > 
> > That most people don't know they should use the new one I 
> understand 
> > though. But I don't see how this will help against that :-)
> 
> It'll make it easy...

You assume they know enough to download it. If they don't know to look
for it, they still won't find it.

But the bottom line: I can see how it would be helpful if you're on a
distro which packages postgresql in a way that prevents you from
installing more than one version at the same time.

//Magnus

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [pgsql-www] [PERFORM] Help speeding up delete

2005-11-17 Thread Steve Wampler
Christopher Kings-Lynne wrote:
>> That most people don't know they should use the new one I understand
>> though. But I don't see how this will help against that :-)
> 
> It'll make it easy...

As the miscreant that caused this thread to get started, let me
*wholeheartedly* agree with Chris.  An easy way to get the pg_dump
for the upgrade target to run with the upgradable source
would work wonders.  (Instructions included, of course.)


-- 
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [pgsql-www] [PERFORM] Help speeding up delete

2005-11-17 Thread Christopher Kings-Lynne
That way if someone wanted to upgrade from 7.2 to 8.1, they 
can just grab the latest dumper from the website, dump their 
old database, then upgrade easily.


But if they're upgrading to 8.1, don't they already have the new
pg_dump? How else are they going to dump their *new* database?


Erm.  Usually when you install the new package/port for 8.1, you cannot 
have both new and old installed at the same time man.  Remember they 
both store exactly the same binary files in exactly the same place.


In my experience not many pgsql admins have test servers or 
the skills to build up test machines with the latest pg_dump, 


I don't, but I still dump with the latest version - works fine both on
linux and windows for me... 


So you're saying you DO have the skills to do it then...

etc.  (Seriously.) In fact, few realise at all that they 
should use the 8.1 dumper.


That most people don't know they should use the new one I understand
though. But I don't see how this will help against that :-)


It'll make it easy...

Chris

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [pgsql-www] [PERFORM] Help speeding up delete

2005-11-17 Thread Magnus Hagander
> > Perhaps we should put a link on the home page underneath LATEST 
> > RELEASEs saying
> > 7.2: de-supported
> > 
> > with a link to a scary note along the lines of the above.
> > 
> > ISTM that there are still too many people on older releases.
> > 
> > We probably need an explanation of why we support so many 
> releases (in 
> > comparison to licenced software) and a note that this does 
> not imply 
> > the latest releases are not yet production (in comparison 
> to MySQL or 
> > Sybase who have been in beta for a very long time).
> 
> By the way, is anyone interested in creating some sort of 
> online repository on pgsql.org or pgfoundry where we can keep 
> statically compiled pg_dump/all for several platforms for 8.1?
> 
> That way if someone wanted to upgrade from 7.2 to 8.1, they 
> can just grab the latest dumper from the website, dump their 
> old database, then upgrade easily.

But if they're upgrading to 8.1, don't they already have the new
pg_dump? How else are they going to dump their *new* database?

> In my experience not many pgsql admins have test servers or 
> the skills to build up test machines with the latest pg_dump, 

I don't, but I still dump with the latest version - works fine both on
linux and windows for me... 

> etc.  (Seriously.) In fact, few realise at all that they 
> should use the 8.1 dumper.

That most people don't know they should use the new one I understand
though. But I don't see how this will help against that :-)

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly