On Thu, 2005-07-14 at 00:19 -0700, Relaxin wrote:
> Before I ask, I don't want to start a war.
>
> Can someone here give me an honest opinion of how PostgresSQL (PG) is better
> than Firebird on Windows?
A colleague of mine has made some benchmarks using those two:
http://www.1006.org/pg/postgr
> When I fire a query to search a debtor id, it took around 5 seconds
> to return an answer for a query [...]
Are you sure that time is actually spent in the database engine?
Maybe there are DNS resolving issues or something...
Did you try to execute the queries directly on the server from
the
Hi,
I have the following test setup:
* PG 8.0.4 on Linux (Centos 4) compiled from source.
* DB schema: essentially one table with a few int columns and
one bytea column that stores blobs of 52000 bytes each, a
primary key on one of the int columns.
* A test client was written in C using lib
>>Is there a better, faster way to do these inserts?
>
> COPY is generally the fastest way to do bulk inserts (see
> PQputCopyData).
Thanks :)
I'll give that I try and report the results here later.
Bye, Chris.
---(end of broadcast)---
TIP 4: Ha
>> Am I correct in assuming that even though I'm passing my 52000
>> bytes as a (char *) to PQexecPrepared(), encoding/decoding is
>> happening (think 0 -> \000) somewhere in the transfer?
>
> Are you specifying it as a text or binary parameter? Have you looked to
> see if the stored data is what
> On Tue, Oct 25, 2005 at 03:44:36PM +0200, Chris Mair wrote:
>>Is there a better, faster way to do these inserts?
>
> COPY is generally the fastest way to do bulk inserts (see
> PQputCopyData).
Hi,
I've rewritten the testclient now to use COPY, but I'm getting
th
> I'm CPU-bound with an I/O well below what my disks could do :(
> [...]
>
> PS1: someone off-list suggested using oprofile, which I will do.
I've used oprofile and found out that with my test client (lots of
bytea inserts) the server burns a lot of CPU time in pglz_compress.
I'm using random d
Is there any experience with Postgresql and really huge tables? I'm
talking about terabytes (plural) here in a single table. Obviously the
table will be partitioned, and probably spread among several different
file systems. Any other tricks I should know about?
We have a problem of that f
Hi,
with that setup you should vacuum aggressivley.
I'd send a vacuum statement in a third thread every 15 minutes or so.
The table renaming trick doesn't sound very handy or even
necessary...
Bye,
Chris.
> Date: Tue, 22 May 2007 14:38:40 -0400
> From: "Orhan Aglagul" <[EMAIL PROTECTED]>
> T
Fredrik Bertilsson wrote:
Hi,
we are using Postgres on both Solaris servers and Linux servers, and
Postgres are much slower on Solaris servers. We have tested with
different versions of Solaris and Postgres, but the fact remains:
Postgres seems to be much faster on Linux server. Does anybody e
Hi,
Note: I have already vacumm full. It does not solve the problem.
I have a postgres 8.1 database. In the last days I have half traffic
than 4 weeks ago, and resources usage is twice. The resource monitor
graphs also shows hight peaks (usually there is not peaks)
The performarce is getting po
> Additionally, because this company develops hospital information systems,
> if someone knows about a medical institute, which uses Postgresql, and
> happy, please send me infomation. I only now subscribed to the advocacy
> list, and only started to browse the archives.
Hi,
have you seen this c
Hi,
I've got a somewhat puzzling performance problem here.
I'm trying to do a few tests with PostgreSQL 8.1.3 under Solaris
(an OS I'm sort of a newbie in).
The machine is a X4100 and the OS is Solaris 10 1/06 fresh install
according to manual. It's got two SAS disks in RAID 1, 4GB of RAM.
Now
> > > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > > wal_sync_method = fsync (unchanged)
> > > wal_buffers = 128 (was 8)
> > > checkpoint_segments = 128 (was 3)
> > > bgwriter_all_percent = 0 (was 0.333)
> > > bgwriter_all_maxpages = 0 (was 5)
> > > and leaving everyt
appears this didn't make it to the list... resending to the list
directly...
---
> > > Doing what http://blogs.sun.com/roller/page/jkshah suggests:
> > > wal_sync_method = fsync (unchanged)
> > > wal_buffers = 128 (was 8)
> > > checkpoint_segments = 128 (was 3)
> > > bgwriter_all_percent =
> > I've done a few tests.
> >
> > Remounting the fs where $PGDATA lives with "forcedirectio"
> > (together with logging, that is default) did not help
> > (if not harm...) performance.
> >
> >
>
> Sure - forcedirectio on the entire $PGDATA is a definite loss, you only
> want it on $PGDATA/pg_
Hi,
thanks for all replys.
I've done a few tests.
Remounting the fs where $PGDATA lives with "forcedirectio"
(together with logging, that is default) did not help
(if not harm...) performance.
Doing what http://blogs.sun.com/roller/page/jkshah suggests:
wal_sync_method = fsync (unchanged)
w
> > Yeah - looks good! (is the default open_datasync still?). Might be worth
> > trying out the fdatasync method too (ISTR this being quite good... again
> > on Solaris 8, so things might have changed)!
>
> I was just talking to a member of the Solaris-UFS team who recommended that
> we
> test
> >Ok, so I did a few runs for each of the sync methods, keeping all the
> >rest constant and got this:
> >
> >open_datasync 0.7
> >fdatasync 4.6
> >fsync 4.5
> >fsync_writethrough not supported
> >open_sync 0.6
> >
> >in arbitrary units - higher is faster.
> >
> > Chris,
> > Just to make sure the x4100 config is similar to your Linux system, can
> > you verify the default setting for disk write cache and make sure they
> > are both enabled or disabled. Here's how to check in Solaris.
> > As root, run "format -e" -> pick a disk -> cache -> write_cache
Hello :)
What version would PostgreSQL 8.1.4 be?
> I'm running a benchmark with theses 3 databases, and the first results
> are not very good for PostgreSQL.
Could you give us some more infos about the box' performance while you
run the PG benchmark? A few minutes output of "vmstat 10" maybe? Wh
> > Could you give us some more infos about the box' performance while you
> > run the PG benchmark? A few minutes output of "vmstat 10" maybe? What
> > does "top" say?
>
> >
> Here, an extract from the vmstat 3 during the test, you can see that
> my problem is probably a very high disk usage (wr
Hi,
I find this very helpful:
Lowering the priority of a PostgreSQL query
http://weblog.bignerdranch.com/?p=11
Now I was wondering whether one could have a
SELECT pg_setpriority(10);
executed automatically each time a certain user
connects (not necessarily using psql)?
Any ideas if and ho
> > I find this very helpful:
> > Lowering the priority of a PostgreSQL query
> > http://weblog.bignerdranch.com/?p=11
>
> That guy doesn't actually have the foggiest idea what he's doing.
> The reason there is no built-in capability to do that is that it *does
> not work well*. Search the l
hich operating system you're using. Diagnosing your
problem might depend on which OS you use...
Finally, explain what you mean by "the age of template0 is
increasing very rapidly", you mean "the size is increasing"?
Bye,
Chris.
--
Chris Mair
http://www.1006.org
lement the Auto Vacuum.
http://www.postgresql.org/docs/8.1/static/maintenance.html#AUTOVACUUM
>
> And also please suggest other steps that i need to
> improve the performance .
>
http://www.powerpostgresql.com/PerfList
Bye,
Chris.
--
Chr
> I am running bechmark test in a 50 GB postgresql database.
> I have the postgresql.conf with all parameters by default.
> In this configuration the database is very, very slow.
>
> Could you please tell which is the best configuration?
>
> My system:
> Pentium D 3.0Ghz
> RAM: 1GB
> HD: 150GB S
> I then re-wrote the page to use a single select query to call all the
> information needed by PHP to draw the screen. That managed to shave it
> down to 3.5 seconds... but this so far is as fast as I can get the
> page to load. Have tried vacuuming and creating indexes but to no
> avail. (increas
Hello,
just recently I held a short course on PG.
One course attendant, Robert Dollinger, got
interested in benchmarking single inserts (since
he currently maintains an application that does
exactly that on Firebird and speed is an issue
there).
He came up with a table that I think is interesti
>
> Date: Mon, 16 Jun 2008 11:06:44 +0200 (CEST)
> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> To: pgsql-performance@postgresql.org
> Subject: function difference(geometry,geometry) is SLOW!
> Message-ID:
> <[EMAIL PROTECTED]>
>
> Hi,
> In my pgsql procedure, i use the function
>
> geometryDif
30 matches
Mail list logo
