On Thu, 3 Apr 2008, MUNAGALA REDDY wrote:
We are using solaris 10 x86/AMD Opteron and postgresql
8.2 on SunFire X2100 , however performance is very
slow in contrast to linux debian in the same platform.
There are some significant differences between how Solaris caches database
files in both o
On Sat, 12 Apr 2008, Craig Ringer wrote:
Speaking of I/O performance with PostgreSQL, has anybody here done any
testing to compare results with LVM to results with the same filesystem on a
conventionally partitioned or raw volume?
There was some chatter on this topic last year; a quick search
Matthew wrote:
On Fri, 11 Apr 2008, Jeff wrote:
Using 4 of these with a dataset of about 30GB across a few files
(Machine has 8GB mem) I went from around 100 io/sec to 330 changing to
noop. Quite an improvement. If you have a decent controller CFQ is
not what you want. I tried deadline as
* Jon Stewart:
>> BYTEA is slower to load and a bit inconvenient to use from DBI, but
>> occupies less space on disk than TEXT or VARCHAR in hex form (17 vs 33
>> bytes with PostgreSQL 8.3).
> Can you clarify the "slower to load" point? Where is that pain point
> in the postgres architecture?
On Fri, 11 Apr 2008, Jeff wrote:
Using 4 of these with a dataset of about 30GB across a few files (Machine has
8GB mem) I went from around 100 io/sec to 330 changing to noop. Quite an
improvement. If you have a decent controller CFQ is not what you want. I
tried deadline as well and it was
On Apr 11, 2008, at 7:22 AM, Albe Laurenz wrote:
After some time of trial and error we found that changing the I/O
scheduling
algorithm to "deadline" improved I/O performance by a factor 4 (!) for
this specific load test.
I was inspired once again to look into this - as I'm recently hitting
> > 1. Which datatype should I use to represent the hash value? UUIDs are
> > also 16 bytes...
>
> BYTEA is slower to load and a bit inconvenient to use from DBI, but
> occupies less space on disk than TEXT or VARCHAR in hex form (17 vs 33
> bytes with PostgreSQL 8.3).
Can you clarify the "s
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> This refers to the performance problem reported in
> http://archives.postgresql.org/pgsql-performance/2008-04/msg00052.php
>
> After some time of trial and error we found that changing the I/O scheduling
> algorithm to "deadline" improved I/O performanc
On Apr 10, 2008, at 5:28 PM, Mark Stosberg wrote:
So, the front-end proxy would have a number of max connections, say
200, and it would connect to another httpd/mod_perl server behind
with a lower number of connections, say 20. If the backend httpd
server was busy, the proxy connection to
Jon Stewart escribió:
> Hello,
>
> I am creating a large database of MD5 hash values. I am a relative
> newb with PostgreSQL (or any database for that matter). The schema and
> operation will be quite simple -- only a few tables, probably no
> stored procedures -- but I may easily end up with seve
* Jon Stewart:
> 1. Which datatype should I use to represent the hash value? UUIDs are
> also 16 bytes...
BYTEA is slower to load and a bit inconvenient to use from DBI, but
occupies less space on disk than TEXT or VARCHAR in hex form (17 vs 33
bytes with PostgreSQL 8.3).
> 2. Does it make sense
1. Which datatype should I use to represent the hash value? UUIDs are
also 16 bytes...
md5's are always 32 characters long so probably varchar(32).
2. Does it make sense to denormalize the hash set relationships?
The general rule is normalize as much as possible then only denormalize
whe
This refers to the performance problem reported in
http://archives.postgresql.org/pgsql-performance/2008-04/msg00052.php
After some time of trial and error we found that changing the I/O scheduling
algorithm to "deadline" improved I/O performance by a factor 4 (!) for
this specific load test.
It
I tried removing the index from the part_master table and got the same
result
Since all the data is in the partitions, the part_master table is empty,
so the index is not useful for your query.
myDB=# explain SELECT min(logdate) FROM part_master;
Proposals :
1- Use plpgsql t
Rajashri Tupe wrote:
Can we write retrieving only 10 records from 4000 records
plz tell me asap
Is this question connected to the previous discussion?
Can you be more specific with your question?
Without having any idea what you're talking about, I'll direct you to
the "LIMIT" clause of th
15 matches
Mail list logo
