Merlin,
The problem is disk. I've got a WD Caviar. hdparm says it does 44MB/sec
(I ran that in single user mode so there was nothing interfering). A WD
Caviar SE SATA in one of my servers at home gets 56MB/sec on a quiescent
system at runlevel 3. What kind of values does hdparm give for a SATA
# [EMAIL PROTECTED] / 2006-08-11 10:12:40 -0400:
I think my Dell Precision 650 has SATA on the motherboard. The boss says
I can order one drive, so what should I get? How much faster is RAID 0+1
than a single drive?
You need 4 disks for 0+1 (or 1+0, also called 10).
--
How many
Richard Broersma Jr wrote:
Views certainly help in managing complexity. They do nothing to improve
query-speed.
Querying a view gets rewritten to queries to the underlying tables on the
fly.
(as long as there are no materialized views, which are still on a the TODO
list)
Would partial indexs
On 8/9/06, Tom Laudeman [EMAIL PROTECTED] wrote:
The speed of the query is (as Michael implies) limited to the rate at which
the disk can seek and read. I have done experiments with views and cursors;
there was no improvement in speed. I've also tried only pulling back
primary keys in the
On Thu, Aug 10, 2006 at 11:00:00AM -0400, Tom Laudeman wrote:
As far as I can tell (from running actual tests) Postgres will not use a
multi-column index when the SELECT is constraining on only one of the
columns in the index.
Excerpt from the 8.1 Release Notes:
* Allow nonconsecutive
Michael Fuhr [EMAIL PROTECTED] writes:
Excerpt from the 8.1 Release Notes:
* Allow nonconsecutive index columns to be used in a multicolumn
index (Tom)
For example, this allows an index on columns a,b,c to be used in
a query with WHERE a = 4 and c = 10.
If you're querying
Hi,
I'm running PostgreSQL version 8 on a dual 2.4GHz Xeon with 1GB of RAM
and an IDE hard drive. My big table has around 9 million records.
Is there a tuning parameter I can change to increase speed of selects?
Clearly, there's already some buffering going on since selecting an
indexed
On Wed, Aug 09, 2006 at 09:19:31AM -0400, Tom Laudeman wrote:
Hi,
I'm running PostgreSQL version 8 on a dual 2.4GHz Xeon with 1GB of RAM
and an IDE hard drive. My big table has around 9 million records.
Is there a tuning parameter I can change to increase speed of selects?
Clearly,
On Wed, Aug 09, 2006 at 03:46:38PM +0200, Martijn van Oosterhout wrote:
On Wed, Aug 09, 2006 at 09:19:31AM -0400, Tom Laudeman wrote:
Is there a tuning parameter I can change to increase speed of selects?
Clearly, there's already some buffering going on since selecting an
indexed ~50,000
What about creating views on areas of the table that are queried often?
I don't know if you have access or the ability to find what type of
trends the table has, in terms of queries, but if you create some views
on frequently visited information, this could also help.
Tom Laudeman wrote:
Louis,Views certainly help in managing complexity. They do nothing to improve query-speed. Querying a view gets rewritten to queries to the underlying tables on the fly.(as long as there are no materialized views, which are still on a the TODO list)
-- GHUM Harald Massapersuadere et
Views certainly help in managing complexity. They do nothing to improve
query-speed.
Querying a view gets rewritten to queries to the underlying tables on the
fly.
(as long as there are no materialized views, which are still on a the TODO
list)
Would partial indexs on the most queried
I'm not so sure about that, when you create a view on a table - at least
with Oracle - which is a subset(the trivial or 'proper' subset is the
entire table view) of the information on a table, when a select is
issued against a table, Oracle at least, determines if there is a view
already on a
Title: Re: [GENERAL] Tuning to speed select
On Wed, 2006-08-09 at 14:58, louis gonzales wrote:
I'm not so sure about that, when you create a view on a table - at least
with Oracle - which is a subset(the trivial or 'proper' subset is the
entire table view) of the information on a table
Michael,
Great suggestion. I've read about CLUSTER, but never had a chance to
use it. The only problem is that this table with 9 million records has
5 or 6 indexes. It is hard to pick the most used, but I'll bet CLUSTER
will make at least one of the queries run very fast, especially for an
On Wed, Aug 09, 2006 at 04:54:00PM -0400, Tom Laudeman wrote:
I'll try CLUSTER (I'm looking forward to that test), but if we really
need speed, it will probably be necessary to create copies of the table,
or copy portions of the table elsewhere (essentially creating
materialized views, I
On Wed, 2006-08-09 at 16:54 -0400, Tom Laudeman wrote:
Great suggestion. I've read about CLUSTER, but never had a chance to use it. The only problem is that this table with 9 million records has 5 or 6 indexes. It is hard to pick the most used, but I'll bet CLUSTER will make at least one
17 matches
Mail list logo
