Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread Craig Ringer
sathiya psql wrote: This might be a silly question, but ... why 8.1 ? If you're doing a major upgrade, why not go straight to 8.3? It's been out long enough that there aren't any obvious nasty bugs, and there have been a fair few fixes and improvements since prior versions. Because am using

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread sathiya psql
In the home page itself they were saying testing ... unstable then we should not use that for live. so i prefer 8.1 . You can get 8.3 from backports: http://www.backports.org/ - it's a debian project to get more up to date versions for existing stable releases (they

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread Craig Ringer
sathiya psql wrote: This might be a silly question, but ... why 8.1 ? how it will be a silly question I thought that some manual changes are required... so am asking this may be argument for functions had changed.. or any other changes... There have been changes for sure... but I

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread sathiya psql
My question is that how to migrate my database to 7.4 to 8.1 that is not only dumping the db and extracting that in 8.1 .. If i do that whether it will work without problem, or i have to do some manual changes is my question...

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread david
On Wed, 12 Mar 2008, sathiya psql wrote: My question is that how to migrate my database to 7.4 to 8.1 that is not only dumping the db and extracting that in 8.1 .. If i do that whether it will work without problem, or i have to do some manual changes is my question... you would need to

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread Craig Ringer
sathiya psql wrote: My question is that how to migrate my database to 7.4 to 8.1 that is not only dumping the db and extracting that in 8.1 .. If i do that whether it will work without problem, or i have to do some manual changes is my question... Start by reading the postgresql 8.0 and 8.1

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread david
On Wed, 12 Mar 2008, sathiya psql wrote: In the home page itself they were saying testing ... unstable you are talking about the debian home page right? then we should not use that for live. so i prefer 8.1 . Debian selected the version of Postgres for Etch about a

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread Chris
[EMAIL PROTECTED] wrote: On Wed, 12 Mar 2008, sathiya psql wrote: In the home page itself they were saying testing ... unstable you are talking about the debian home page right? then we should not use that for live. so i prefer 8.1 . Debian selected the version of

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread sathiya psql
you are talking about the debian home page right? --- no am talking about backports home page..

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread Steinar H. Gunderson
On Wed, Mar 12, 2008 at 12:13:01PM +0530, sathiya psql wrote: My question is that how to migrate my database to 7.4 to 8.1 aptitude install postgresql-8.1 pg_dropcluster 8.1 main pg_upgradecluster 7.4 main /* Steinar */ -- Homepage: http://www.sesse.net/ -- Sent via pgsql-performance

Re: [PERFORM] migration of 7.4 to 8.1

2008-03-12 Thread Vivek Khera
On Mar 12, 2008, at 2:43 AM, sathiya psql wrote: My question is that how to migrate my database to 7.4 to 8.1 that is not only dumping the db and extracting that in 8.1 .. If i do that whether it will work without problem, or i have to do some manual changes is my question... the pg

[PERFORM] 8.3 write performance

2008-03-12 Thread Enrico Sirola
Hello, (you could receive this message twice - I have some email issues sorry) I'm setting up a new DB with Centos 5 (amd64) + postgresql 8.3 installed from the pgsql yum repository. This is a host dedicated to postgresql. From the benchmarks I found here and there on the web, and having digged

[PERFORM] Hardware question for a DB server

2008-03-12 Thread Pascal Cohen
Hello, we plan to buy a dedicated server to host our database. Here is the proposal I was given (with a second identical server fro backup using log shipping): = IBM X3650 (This is a 2U server, can hold 8 Drives) 2 x QC Xeon E5450 (3.0GHz 12MB L2 1333MHz 80W) 8 x 2GB RAM

Re: [PERFORM] Hardware question for a DB server

2008-03-12 Thread Mark Lewis
What type of usage does it need to scale for? How many concurrent connections? What size database? Data warehousing or OLTP-type workloads? Ratio of reads/writes? Do you care about losing data? One question that's likely going to be important depending on your answers above is whether or not

Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC LIMIT 1

2008-03-12 Thread Bruce Momjian
Heikki Linnakangas wrote: Bruce, would you please add this to the 8.4 patch queue so we remember to look at this later? OK, added to queue, but Tom's patch queue comment is: This is useless since it does not represent a complete patch; the provided code calls a lot of Greenplum-private

Re: [PERFORM] Hardware question for a DB server

2008-03-12 Thread Pascal Cohen
Mark Lewis wrote: What type of usage does it need to scale for? How many concurrent connections? What size database? Data warehousing or OLTP-type workloads? Ratio of reads/writes? Do you care about losing data? I expected those questions but I was sure that I would forget or ignore

Re: [PERFORM] Hardware question for a DB server

2008-03-12 Thread Greg Smith
On Wed, 12 Mar 2008, Mark Lewis wrote: One question that's likely going to be important depending on your answers above is whether or not you're getting a battery-backed write cache for that ServeRAID-8K. Apparently there's a 8k-l and an regular 8-k; the l doesn't have the cache, so if this

[PERFORM] Are piped columns indexable

2008-03-12 Thread Mark Steben
Hi all, Just upgraded to 8.2.5. Given table t with columns a, b, c, d And index on t using btree (a,b) Is this indexable: Select * from t where a || b = '124cab' (or whatever) Assume a and b are defined as char(3) I have tried various op classes and so far have just

Re: [PERFORM] Are piped columns indexable

2008-03-12 Thread Merlin Moncure
On Wed, Mar 12, 2008 at 4:38 PM, Mark Steben [EMAIL PROTECTED] wrote: Given table t with columns a, b, c, d And index on t using btree (a,b) Is this indexable: Select * from t where a || b = '124cab' (or whatever) Assume a and b are defined as char(3) I have tried various op

[PERFORM] Repeated execution of identical subqueries

2008-03-12 Thread Craig Ringer
Hi I've been wondering about postgresql's handling of repeated subqueries in statements for a while, and thought I'd ask here. If the exact same subquery appears in multiple places in a complex query, it seems to be executed separately each time it appears. I'm wondering if there's any way,

[PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

2008-03-12 Thread Craig James
I just received a new server and thought benchmarks would be interesting. I think this looks pretty good, but maybe there are some suggestions about the configuration file. This is a web app, a mix of read/write, where writes tend to be insert into ... (select ...) where the resulting insert

Re: [PERFORM] Repeated execution of identical subqueries

2008-03-12 Thread Tom Lane
Craig Ringer [EMAIL PROTECTED] writes: Is there any way to get postgresql to detect such repeated query parts and evaluate them only once? No, not at the moment. In principle the planner could look for such duplicates, but it'd be wasted cycles so much of the time that I'd be loath to do it.

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

2008-03-12 Thread Scott Marlowe
On Wed, Mar 12, 2008 at 9:55 PM, Craig James [EMAIL PROTECTED] wrote: I just received a new server and thought benchmarks would be interesting. I think this looks pretty good, but maybe there are some suggestions about the configuration file. This is a web app, a mix of read/write, where

Re: [PERFORM] Benchmark: Dell/Perc 6, 8 disk RAID 10

2008-03-12 Thread Joshua D. Drake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 12 Mar 2008 21:55:18 -0700 Craig James [EMAIL PROTECTED] wrote: Diffs from original configuration: max_connections = 1000 shared_buffers = 400MB work_mem = 256MB max_fsm_pages = 100 max_fsm_relations = 5000 wal_buffers = 256kB