Re: [PERFORM] Overlaping indexes

2004-02-02 Thread Tomasz Myrta
Dnia 2004-02-02 15:46, Uytkownik Rigmor Ukuhe napisa: Hi, I have many indexes somehow overlaping like: ... btree (STATUS, VISIBLE, NP_ID); ... btree (STATUS, VISIBLE); is perfomance gained by more exact index worth overhead with managing indexes. The second (2 columns) index is useless - it's

[PERFORM] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Josh Berkus
Folks, I've had requests from a couple of businesses to see results of infomal MySQL +InnoDB vs. PostgreSQL tests.I know that we don't have the setup to do full formal benchmarking, but surely someone in our community has gone head-to-head on your own application? -- -Josh Berkus Aglio

[PERFORM] Mainframe Linux + PostgreSQL

2004-02-02 Thread Josh Berkus
Folks, Is anyone on this list using PostgreSQL on a mini or mainframe platform? If so, drop me a line. Thanks! -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with

Re: [PERFORM] Overlaping indexes

2004-02-02 Thread scott.marlowe
On Mon, 2 Feb 2004, Tomasz Myrta wrote: Dnia 2004-02-02 15:46, U?ytkownik Rigmor Ukuhe napisa3: Hi, I have many indexes somehow overlaping like: ... btree (STATUS, VISIBLE, NP_ID); ... btree (STATUS, VISIBLE); is perfomance gained by more exact index worth overhead with managing

Re: [PERFORM] Overlaping indexes

2004-02-02 Thread Tomasz Myrta
Dnia 2004-02-02 19:30, Uytkownik scott.marlowe napisa: Not entirely, since it only has to sort two columns, it will be smaller, and will therefore be somewhat faster. Can you say something more about it? Will it be enough faster to keep them both? Did anyone make such tests? Regards, Tomasz

Re: [PERFORM] Overlaping indexes

2004-02-02 Thread scott.marlowe
On Mon, 2 Feb 2004, Tomasz Myrta wrote: Dnia 2004-02-02 19:30, U┬┐ytkownik scott.marlowe napisa┬│: Not entirely, since it only has to sort two columns, it will be smaller, and will therefore be somewhat faster. Can you say something more about it? Will it be enough faster to keep them

[PERFORM] Increasing number of PG connections.

2004-02-02 Thread Kevin Barnard
I am running a Dual Xeon hyperthreaded server with 4GB RAM RAID-5. The only thing running on the server is Postgres running under Fedora. I have a 700 connection limit. The DB is setup as a backend for a very high volume website. Most of the queries are simple, such as logging accesses,

Re: [PERFORM] Overlaping indexes

2004-02-02 Thread Rod Taylor
On Mon, 2004-02-02 at 13:43, Tomasz Myrta wrote: Dnia 2004-02-02 19:30, Uytkownik scott.marlowe napisa: Not entirely, since it only has to sort two columns, it will be smaller, and will therefore be somewhat faster. Can you say something more about it? Will it be enough faster to keep

[PERFORM] pg_stat_activity

2004-02-02 Thread Orion Henry
Quick Question, The full query listed in pg_stat_activity is getting truncated. Does anyone know how I can see the full query in progress? -- Orion Henry [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part

Re: [PERFORM] Increasing number of PG connections.

2004-02-02 Thread Qing Zhao
I am new here. I have a question related to this in some way. Our web site needs to upload a large volume of data into Postgres at a time. The performance deterioates as number of rows becomes larger. When it reaches 2500 rows, it never come back to GUI. Since the tests were run through GUI,

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Robert Treat
On Mon, 2004-02-02 at 12:21, Josh Berkus wrote: Folks, I've had requests from a couple of businesses to see results of infomal MySQL +InnoDB vs. PostgreSQL tests.I know that we don't have the setup to do full formal benchmarking, but surely someone in our community has gone

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Adam Ruth
Josh, I evaluated MySQL + InnoDB briefly for a project, once. I didn't get very far because of some severe limitations in MySQL. I had to import all of the data from an existing database (MS SQL). One of the tables was about 8 million rows, 10 fields, and had 5 indexes. I found it quite

inserting large number of rows was: Re: [PERFORM] Increasing number of PG connections.

2004-02-02 Thread scott.marlowe
On Mon, 2 Feb 2004, Qing Zhao wrote: I am new here. I have a question related to this in some way. Our web site needs to upload a large volume of data into Postgres at a time. The performance deterioates as number of rows becomes larger. When it reaches 2500 rows, it never come back to

Bulk Record upload (was Re: [PERFORM] Increasing number of PG connections)

2004-02-02 Thread Richard Huxton
On Monday 02 February 2004 19:39, Qing Zhao wrote: I am new here. I have a question related to this in some way. Hmm - no real connection I can see - might have been better to start a new thread rather than replying to this one. Also, it is usually considered best practice not to quote large

Re: [PERFORM] Increasing number of PG connections.

2004-02-02 Thread Kevin Barnard
On 2 Feb 2004 at 13:58, scott.marlowe wrote: what do you mean at 2 GB? Is that how much is in kernel cache plus buffer, plus used, plus etc??? Could you give us the top of top output to make sure? If most of that is kernel cache, then that's fine. 2GB was total system memory. We

Re: [PERFORM] Increasing number of PG connections.

2004-02-02 Thread scott.marlowe
On Mon, 2 Feb 2004, Kevin Barnard wrote: On 2 Feb 2004 at 13:58, scott.marlowe wrote: what do you mean at 2 GB? Is that how much is in kernel cache plus buffer, plus used, plus etc??? Could you give us the top of top output to make sure? If most of that is kernel cache, then that's

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Christopher Kings-Lynne
One more thing that annoyed me. If you started a process, such as a large DDL operation, or heaven forbid, a cartesian join (what? I never do that!). I believe InnoDB also has O(n) rollback time. eg. if you are rolling back 100 million row changes, it takes a long, long time. In PostgreSQL

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Christopher Kings-Lynne
Seriously, I am tired of this kind of question. You gotta get bold enough to stand up in a meeting like that, say guy's, you can ask me how this compares to Oracle ... but if you're seriously asking me how this compares to MySQL, call me again when you've done your homework. Hey at least I

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Christopher Kings-Lynne
Um, wrong. We don't lock rows for SELECT. No, but Chris is correct that we could do with having some kind of shared lock facility at the row level. Out of interest, what is it about this particular task that's so hard? (Not that I could code it myself). But surely you can use the same sort of

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Tom Lane
Christopher Kings-Lynne [EMAIL PROTECTED] writes: No, but Chris is correct that we could do with having some kind of shared lock facility at the row level. Out of interest, what is it about this particular task that's so hard? Keeping track of multiple lockers in a fixed amount of disk

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Christopher Kings-Lynne
Out of interest, what is it about this particular task that's so hard? Keeping track of multiple lockers in a fixed amount of disk space. Why not look at how InnoDB does it? Or is that not applicable? ---(end of broadcast)--- TIP 3: if

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Josh Berkus
Chris, Which does a shared lock on a row as opposed to a write lock, hence avoiding nasty foreign key deadlocks... Um, wrong. We don't lock rows for SELECT. Unless you meant something else? Am I not following you? -- -Josh Berkus Aglio Database Solutions San Francisco

Re: [PERFORM] [pgsql-advocacy] MySQL+InnoDB vs. PostgreSQL test?

2004-02-02 Thread Christopher Kings-Lynne
Um, wrong. We don't lock rows for SELECT. Unless you meant something else? Am I not following you? I mean row level shared read lock. eg. a lock that says, you can read but you cannot delete. It's what postgres needs to alleviate its foreign key trigger deadlock problems. Chris