Please help me to set up optimal values in the postgresql.conf file for
PostgreSQL 8.2.3
Can you please give us an advice, which of your DBs and which
configuration should we take for a project that has the following
parameters:
1. DB size: 25-30Gb
2. number of tables: 100 - 150
3. max
Hello,
> The next question then is whether anything in your postgres configuration
> is preventing it getting useful performance from the OS. What settings
> have you changed in postgresql.conf?
The only options not commented out are the following (it's not even
tweaked for buffer sizes and such,
>On sequential read speed HDs outperform flash disks... only on random
>access the flash disks are better. So if your application is a DW one,
>you're very likely better off using HDs.
This looks likely to be a non-issue shortly, see here:
http://www.reghardware.co.uk/2007/03/27/sams_doubles_ssd_
On Tue, 3 Apr 2007, Geoff Tolley wrote:
Ron wrote:
At 07:07 PM 4/3/2007, Ron wrote:
> For random IO, the 3ware cards are better than PERC
>
> > Question: will 8*15k 73GB SCSI drives outperform 24*7K 320GB SATA II
> drives?
>
> Nope. Not even if the 15K 73GB HDs were the brand new Savv
You might also ask on:
[EMAIL PROTECTED]
People are pretty candid there.
~BAS
On Tue, 2007-04-03 at 15:13 -0700, [EMAIL PROTECTED] wrote:
> Question: will 8*15k SCSI drives outperform 24*7K SATA II drives?
--
Brian A. Seklecki <[EMAIL PROTECTED]>
Collaborative Fusion, Inc.
--
Ron wrote:
At 07:07 PM 4/3/2007, Ron wrote:
For random IO, the 3ware cards are better than PERC
> Question: will 8*15k 73GB SCSI drives outperform 24*7K 320GB SATA II
drives?
Nope. Not even if the 15K 73GB HDs were the brand new Savvio 15K
screamers.
Example assuming 3.5" HDs and RAID 10
At 07:07 PM 4/3/2007, Ron wrote:
For random IO, the 3ware cards are better than PERC
> Question: will 8*15k 73GB SCSI drives outperform 24*7K 320GB SATA
II drives?
Nope. Not even if the 15K 73GB HDs were the brand new Savvio 15K screamers.
Example assuming 3.5" HDs and RAID 10 => 4 15K 73GB
For random IO, the 3ware cards are better than PERC
> Question: will 8*15k 73GB SCSI drives outperform 24*7K 320GB SATA II drives?
Nope. Not even if the 15K 73GB HDs were the brand new Savvio 15K screamers.
Example assuming 3.5" HDs and RAID 10 => 4 15K 73GB vs 12 7.2K 320GB
The 15K's are 2x f
We need to upgrade a postgres server. I'm not tied to these specific
alternatives, but I'm curious to get feedback on their general
qualities.
SCSI
dual xeon 5120, 8GB ECC
8*73GB SCSI 15k drives (PERC 5/i)
(dell poweredge 2900)
SATA
dual opteron 275, 8GB ECC
24*320GB SATA II 7.2k d
On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Alex Deucher" <[EMAIL PROTECTED]> writes:
> Turning off bitmapscan ends up doing a sequential scan. Turning off
> both bitmapscan and seqscan results in a bitmap heap scan. It doesn't
> seem to want to use the index at all. Any ideas?
The "ORed
On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Alex Deucher" <[EMAIL PROTECTED]> writes:
> Turning off bitmapscan ends up doing a sequential scan. Turning off
> both bitmapscan and seqscan results in a bitmap heap scan. It doesn't
> seem to want to use the index at all. Any ideas?
The "ORed
Kevin Grittner wrote:
Management has simply given a mandate that the software be independent
of OS and database vendor, and to use Java to help with the OS independence.
... we write all of our queries in ANSI SQL in our own query tool, parse it,
and generate Java classes to run it.
A better so
On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Alex Deucher" <[EMAIL PROTECTED]> writes:
> Turning off bitmapscan ends up doing a sequential scan. Turning off
> both bitmapscan and seqscan results in a bitmap heap scan. It doesn't
> seem to want to use the index at all. Any ideas?
The "ORed
"Alex Deucher" <[EMAIL PROTECTED]> writes:
> Turning off bitmapscan ends up doing a sequential scan. Turning off
> both bitmapscan and seqscan results in a bitmap heap scan. It doesn't
> seem to want to use the index at all. Any ideas?
The "ORed indexscans" plan style that was in 7.4 isn't ther
On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 4/3/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> > On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
(('{AB6698130,AB7076908,AB6499382,AB643,AB6385893,AB6378237,AB7146973,AB7127
On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
On 4/3/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
>
(('{AB6698130,AB7076908,AB6499382,AB643,AB6385893,AB6378237,AB7146973,AB7127138,AB7124531,AB7124513,AB7123427,AB7121183,AB7121036,AB7
On 4/3/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
(('{AB6698130,AB7076908,AB6499382,AB643,AB6385893,AB6378237,AB7146973,AB7127138,AB7124531,AB7124513,AB7123427,AB7121183,AB7121036,AB7110101,AB7100321,AB7089845,AB7088750,AB7031384,AB7021188
On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
(('{AB6698130,AB7076908,AB6499382,AB643,AB6385893,AB6378237,AB7146973,AB7127138,AB7124531,AB7124513,AB7123427,AB7121183,AB7121036,AB7110101,AB7100321,AB7089845,AB7088750,AB7031384,AB7021188,AB7006144,AB6988331,AB6973865,AB6966775,AB6935066,AB6
On Apr 3, 2007, at 16:00 , Alan Hodgson wrote:
On Tuesday 03 April 2007 12:47, "A.M."
<[EMAIL PROTECTED]> wrote:
On Apr 3, 2007, at 15:39 , C. Bergström wrote:
I would like to use transactional semantics over tables that can
disappear whenever the server fails. memcached does not offer that.
On Tuesday 03 April 2007 12:47, "A.M." <[EMAIL PROTECTED]> wrote:
> On Apr 3, 2007, at 15:39 , C. Bergström wrote:
> I would like to use transactional semantics over tables that can
> disappear whenever the server fails. memcached does not offer that.
How would temporary tables?
--
Ginsberg's Th
On Apr 3, 2007, at 15:39 , C. Bergström wrote:
A.M. wrote:
Indeed... I looked through the official TODO list and was unable
to find an entry for global temporary tables- such a thing would
be ideal for any transient data such as web sessions or
materialized views. Is there any reason why
A.M. wrote:
Indeed... I looked through the official TODO list and was unable to
find an entry for global temporary tables- such a thing would be ideal
for any transient data such as web sessions or materialized views. Is
there any reason why global temp tables shouldn't be implemented?
(And, n
On 4/3/07, Alex Deucher <[EMAIL PROTECTED]> wrote:
On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Deucher" <[EMAIL PROTECTED]> writes:
> > and here are the query plans referenced in my last email (apologies if
> > you get these twice, they didn't seem to go through the first time,
> > per
On Apr 3, 2007, at 11:51 AM, Dimitri wrote:
Well, to check if there is a real potential gain all we need is a
small comparing test using PgSQL compiled with LOG block size
equal to
say 1K and direct IO enabled.
Rgds,
-Dimitri
On 3/30/07, Kenneth Marshall <[EMAIL PROTECTED]> wrote:
> On Fr
Indeed... I looked through the official TODO list and was unable to
find an entry for global temporary tables- such a thing would be
ideal for any transient data such as web sessions or materialized
views. Is there any reason why global temp tables shouldn't be
implemented? (And, no, I'm no
Arnau <[EMAIL PROTECTED]> writes:
> MySQL manual says:
> "The MEMORY storage engine creates tables with contents that are stored
> in memory. As indicated by the name, MEMORY tables are stored in memory.
> Is there anything similar in PostgreSQL?
As long as you have shared_buffers large enough (o
Arnau,
Is there anything similar in PostgreSQL? The idea behind this is how I
can do in PostgreSQL to have tables where I can query on them very often
something like every few seconds and get results very fast without
overloading the postmaster.
If you're only querying the tables every few sec
Hi all,
In MySQL when you create a table you can define something like:
CREATE TABLE `sneakers` (
`sneaker_id` char(24) NOT NULL,
`sneaker_time` int(10) unsigned NOT NULL default '0',
`sneaker_user` int(10) unsigned NOT NULL default '0',
UNIQUE KEY `sneaker_id` (`sneaker_id`)
) ENGINE=
Guillaume,
which shows the index on primary keys is used, but is always read
from disk.
or, more likely, from the FS cache.
But, the clock time used for the request is actually identical
when using -B 1000 or -B 2. I suppose the kernel is bringing
the performance difference thanks to fi
Have you looked at the pg_stat_* views? You must enable stats collection
to see any data in them, but that's probably what you're looking for.
On Tue, 3 Apr 2007, Jean Arnaud wrote:
Hi
Is there a way to get the cache hit ratio in PostGreSQL ?
Cheers
--
-- Jean Arnaud
-- Projet SARDES
-- INR
Set log_executor_stats=true;
Then look in the log after running statements (or tail -f logfile).
- Luke
On 4/3/07 7:12 AM, "Jean Arnaud" <[EMAIL PROTECTED]> wrote:
> Hi
>
> Is there a way to get the cache hit ratio in PostGreSQL ?
>
> Cheers
---(end of broadcast)--
Folks,
to close topic with "LOG block size=1K" idea - I took a time to test
it (yes) and in best cases there is only 15% gain comparing to 8K -
storage protocol is quite heavy itself, so less or more data sent
within it doesn't reduce service time too much... As well even this
gain is quickly dec
On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Alex Deucher" <[EMAIL PROTECTED]> writes:
> and here are the query plans referenced in my last email (apologies if
> you get these twice, they didn't seem to go through the first time,
> perhaps due to size?). I cut out the longer ones.
The first
Erik,
> Well, our application code itself doesn't retry queries if the db is
> taking a long time to respond. However, we do have a number of our
> servers making db connections via pgpool so you may be on to
> something here. While I will be taking these questions to the pgpool
> lists, I'll po
Jean Arnaud writes:
> Hi
>
> Is there a way to get the cache hit ratio in PostGreSQL ?
When you activate:
stats_block_level = true
stats_row_level = true
you will get global statistics, per table and per index, about
read disk blocks and saved reads thanks to buffers.
That said, I'd
Hi
Is there a way to get the cache hit ratio in PostGreSQL ?
Cheers
--
-- Jean Arnaud
-- Projet SARDES
-- INRIA Rhône-Alpes / LSR-IMAG
-- http://sardes.inrialpes.fr/~jarnaud
---(end of broadcast)---
TIP 4: Have you searched our list archives?
36 matches
Mail list logo
