Roman Neuhauser wrote:
# [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?
If you can order one drive, get a drive that is twice
# [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 Viet
On 8/11/06, Tom Laudeman <[EMAIL PROTECTED]> wrote:
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
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
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 quer
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 i
Reece,
We have some multi-column indexes. Speed of insert, update, and delete
are not an issue since this data is essentially static: write-once,
read-many.
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 o
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 ho
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 o
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 o
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
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
inde
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 th
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 t
> 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 queri
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 programmareHara
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:
Hi
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 ~5
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
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 ~50,
20 matches
Mail list logo
