[PERFORM] PostgreSQL and Linux 2.6 kernel.

As part of my ongoing evaluation of PostgreSQL I have been doing a little stress testing. I though I would share an interesting result here.. Machine spec: 500 MHz PIII 256MB RAM old-ish IDE HD (5400RPM) Linux 2.4.22 kernel (Madrake 9.2) I have PostgreSQL 7.4.1 installed and have managed to

[PERFORM] single index on more than two coulumns a bad thing?

Hi, I remember reading a post ages ago, maybe from Vadim, about the fact that people creating indices on more than two columns will be the first to be put againts the wall when the revolution comes... sort of... Is it always bad to create index xx on yy (field1, field2, field3); I guess the

Re: [PERFORM] single index on more than two coulumns a bad thing?

Palle, Is it always bad to create index xx on yy (field1, field2, field3); No, it seldom bad, in fact.I have some indexes that run up to seven columns, becuase they are required for unique keys. Indexes of 3-4 columns are often *required* for many-to-many join tables. I'm afraid that

Re: [PERFORM] single index on more than two coulumns a bad thing?

Josh Berkus [EMAIL PROTECTED] writes: Is it always bad to create index xx on yy (field1, field2, field3); I'm afraid that you've been given some misleading advice. I'd say it's a matter of getting your optimizations straight. If you have a query that can make use of that index, and the query

Re: [PERFORM] Index Performance Help

Damien Dougan [EMAIL PROTECTED] writes: Sample analyze output for an initial query: hydradb=# explain analyze select * from pvsubscriber where actorid = 'b3432-asdas-232-Subscriber793500'; I take it pvsubscriber is a view? What's the definition of your view? - Index Scan using

Re: [PERFORM] single index on more than two coulumns a bad thing?

Palle Girgensohn [EMAIL PROTECTED] writes: Is it always bad to create index xx on yy (field1, field2, field3); All generalisations are false... Seriously, it's true that as the length of your index key gets longer the harder and harder it is to justify it. That doesn't mean they're always

Re: [PERFORM] PostgreSQL and Linux 2.6 kernel.

Gary Doades [EMAIL PROTECTED] writes: As a test in PosgreSQL I issued a statement to update a single column of a table containing 2.8 million rows with the values of a column in a table with similar rowcount. Using the above spec I had to stop the server after 17 hours. The poor thing was

Re: [PERFORM] PostgreSQL and Linux 2.6 kernel.

The post was not intended to be content-rich, just my initial feedback after only just switching to 2.6. Since I had largely given up on this particular line of attack using 2.4 I didn't think to do a detailed analysis at this time. I was also hoping that others would add to the discussion.