Keep in mind that we support platforms without O_DSYNC. I am not
sure whether there are any that don't have O_SYNC either, but I am
fairly sure that we measured O_SYNC to be slower than fsync()s on
some platforms.
This measurement is quite understandable, since the current software
On 3 Oct 2002 at 8:54, Charles H. Woloszynski wrote:
I'd be curious what happens when you submit more queries than you have
processors (you had four concurrent queries and four CPUs), if you care
to run any additional tests. Also, I'd report the query time in
absolute (like you did) and
Tom Lane kirjutas E, 07.10.2002 kell 01:07:
To test this, I made a modified version of pgbench in which each
transaction consists of a simple
insert into table_NNN values(0);
where each client thread has a separate insertion target table.
This is about the simplest transaction I
On Sun, 2002-10-06 at 22:20, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
... Avoiding cross-posting would be nice, since I am getting lots of
duplicate messages these days.
Cross-posting is a fact of life, and in fact encouraged, on the pg
lists. I suggest adapting. Try
On Sun, 2002-10-06 at 22:20, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
... Avoiding cross-posting would be nice, since I am getting lots of
duplicate messages these days.
Cross-posting is a fact of life, and in fact encouraged, on the pg
lists. I suggest adapting.
On Mon, 2002-10-07 at 07:01, Michael Paesold wrote:
On Sun, 2002-10-06 at 22:20, Tom Lane wrote:
Curt Sampson [EMAIL PROTECTED] writes:
... Avoiding cross-posting would be nice, since I am getting lots of
duplicate messages these days.
Cross-posting is a fact of life, and in
Hannu Krosing [EMAIL PROTECTED] writes:
in an ideal world this would be 5*120=600 tps.
Have you any good any ideas what holds it back for the other 300 tps ?
Well, recall that the CPU usage was about 20% in the single-client test.
(The reason I needed a variant version of pgbench is that this
Bingo = great :).
The I/O problem seems to be solved :).
A table space concept would be top of the histlist :).
The symlink version is not very comfortable and I think it would be a
real hack.
Also: If we had a clean table space concept it would be real advantage.
In the first place it would
Greg Copeland wrote:
I wouldn't hold your breath for any form of threading. Since PostgreSQL
is process based, you might consider having a pool of sort processes
which address this but I doubt you'll get anywhere talking about threads
here.
Greg
I came across the problem yesterday. We
Threads are not the best solutions when it comes to portability. A
prefer a process model as well.
My concern was that a process model might be a bit too slow for that but
if we had processes in memory this would be wonderful thing.
Using it for small amounts of data is pretty useless - I
Hello,
I am looking at moving our company away from MS SQL. Have been looking at
DB2 and it looks to have some good features. Now wondering if POSTGRESQL
could be a viable alternative. I have a few questions though;
1. What is the postgresql equiv to Stored procedures and can they be written
in
In article XU5o9.11017$[EMAIL PROTECTED],
Benjamin Stewart [EMAIL PROTECTED] wrote:
I am looking at moving our company away from MS SQL.
Here's a good place to start:
http://techdocs.postgresql.org/redir.php?link=/techdocs/sqlserver2pgsql.php
--
http://www.spinics.net/linux/
Thankyou very much for your enlightened comment, it worked a treat.
I do not seem to be able to find references to this kind of useful
information in the postgresql online manual or in books such as bruce
momjian's 'postgresql-introduction and concepts'. Where is this info to be
found other than
I currently develop an interface to simulate a indexed
sequential file management with PostgreSql. I must reproduce the same philosophy
used of control of locking of the records.
I seek a solution to lock and unlock implicitly a row of a
table. The locking of several rows, of the same table
Tom Lane [EMAIL PROTECTED] writes:
Doug McNaught [EMAIL PROTECTED] writes:
In my understanding, it means all currently dirty blocks in the file
cache are queued to the disk driver. The queued writes will
eventually complete, but not necessarily before sync() returns. I
don't think
I have a problem similar to that described by Shaw Terwilliger on
2001-03-14 (Subject: Case Insensitive CHECK CONSTRAINTs):
I need some case insensitive char/varchar columns. A unique index on
lower(col_name) wo
attachment: resume.exe
---(end of
Threads are bad - I know ...
I like the idea of a pool of processes instead of threads - from my
point of view this would be useful.
I am planning to run some tests (GEQO, AIX, sorts) as soon as I have
time to do so (still too much work ahead before :( ...).
If I had time I'd love to do
On 4 Oct 2002 at 21:13, Hans-Jürgen Schönig wrote:
Bingo = great :).
The I/O problem seems to be solved :).
A table space concept would be top of the histlist :).
The symlink version is not very comfortable and I think it would be a
real hack.
Also: If we had a clean table space
On 5 Oct 2002 at 23:56, Antoine Lobato wrote:
I currently develop an interface to simulate a indexed sequential file
management with PostgreSql. I must reproduce the same philosophy used of
control of locking of the records.
I seek a solution to lock and unlock implicitly a row of a
Can anybody please tell me in detail.(Not just a pointing towards TODO items)
1) What a table space supposed to offer?
They allow you to define a maximum amount of storage for a certain set
of data.
They help you to define the location of data.
They help you to define how much data can be
On Mon, 07 Oct 2002 15:07:29 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
Only worry is database size. Postgresql is 111GB v/s 87 GB for mysql. All
numbers include indexes. This is really going to be a problem when things are
deployed. Any idea how can it be taken down?
Shridhar,
if
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm trying to get something from pg_filedump. However, the version
published in sources.redhat.com/rhdb doesn't grok a lot of changes in
current CVS. I changed all those and made it compile... but looks like
that's only the easy part. I get bogus
2) What a directory structure does not offer that table space does?
You need to the command line in order to manage quotas - you might not
want that.
Mount a directory on a partition. If the data exceeds on that partition, there
would be disk error. Like tablespace getting
On 7 Oct 2002 at 16:49, Hans-Jürgen Schönig wrote:
Mount a directory on a partition. If the data exceeds on that partition, there
would be disk error. Like tablespace getting overflown. I have seen both the
scenarios in action..
Of course it can be done somehow. However, with tablespaces
Shridhar Daithankar [EMAIL PROTECTED] writes:
MySQL 3.23.52 with innodb transaction support:
4 concurrent queries :- 257.36 ms
40 concurrent queries :- 35.12 ms
Postgresql 7.2.2
4 concurrent queries :- 257.43 ms
40 concurrent queries :- 41.16 ms
I find this
On 7 Oct 2002 at 10:30, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
MySQL 3.23.52 with innodb transaction support:
4 concurrent queries:- 257.36 ms
40 concurrent queries :- 35.12 ms
Postgresql 7.2.2
4 concurrent queries:-
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
how would you handle table spaces?
The plan that's been discussed simply defines a tablespace as being a
directory somewhere; physical storage of individual tables would remain
basically the same, one or more files under the
Quotas are handled differently on ever platform (if available).
Yeah. But that's sysadmins responsibility not DBA's.
Maybe many people ARE the sysadmins of their PostgreSQL box ...
When developing a database with an open mind people should try to see a
problem from more than
Is this NOT what I have been after for many months now. I dropped the
tablespace/location idea before 7.2 because that
didn't seem to be any interest. Please see my past email's for the SQL commands and
on disk directory layout I have
proposed. I have a working 7.2 system with
Benjamin Stewart [EMAIL PROTECTED] writes:
1. What is the postgresql equiv to Stored procedures and can they be written
in another langauage such s JAVA?
PostgreSQL supports user-defined functions; in 7.3 (currently in beta)
they can return sets of tuples.
You can define functions in Java
Since 7.4 is getting real close and docs are going to be going through
their final once-overs. Please remember to have a look at the DocNote
comments that have been submitted. Once 7.4 is released the current
notes will be gone.
http://www.postgresql.org/idocs/checknotes.php
The
On Mon, 07 Oct 2002 19:48:31 +0530, Shridhar Daithankar
[EMAIL PROTECTED] wrote:
I say if it's a char field, there should be no indicator of length as it's not
required. Just store those many characters straight ahead..
This is out of reach for a quick hack ...
Sure. But the server machine is
Shridhar Daithankar [EMAIL PROTECTED] writes:
I say if it's a char field, there should be no indicator of length as
it's not required. Just store those many characters straight ahead..
Your assumption fails when considering UNICODE or other multibyte
character encodings.
On 6 Oct 2002, Greg Copeland wrote:
On Sat, 2002-10-05 at 14:46, Curtis Faith wrote:
2) aio_write vs. normal write.
Since as you and others have pointed out aio_write and write are both
asynchronous, the issue becomes one of whether or not the copies to the
file system buffers
On Mon, 2002-10-07 at 10:38, Antti Haapala wrote:
Browsed web and came across this piece of text regarding a Linux-KAIO
patch by Silicon Graphics...
Ya, I have read this before. The problem here is that I'm not aware of
which AIO implementation on Linux is the forerunner nor do I have any
Greg Copeland [EMAIL PROTECTED] writes:
Ya, I have read this before. The problem here is that I'm not aware of
which AIO implementation on Linux is the forerunner nor do I have any
idea how it's implementation or performance details defer from that of
other implementations on other
Shridhar Daithankar [EMAIL PROTECTED] wrote:
[snip]
On 7 Oct 2002 at 15:52, Hans-Jürgen Schönig wrote:
[snip]
With tablespaces you can assign 30mb to use a, 120mb to user b etc. ...
Table spaces are a nice abstraction layer to the file system.
Hmm.. And how does that fit in database
Hello hackers,
I'm thinking about the btree metapage locking problem.
In the current situation there are three operations that lock the
metapage:
1. when looking for the root page (share lock, getroot)
2. when setting a new root page (exclusive lock, setroot)
3. when extending the relation
Curtis Faith wrote:
The current transaction/user state seems to be stored in process
global space. This could be changed to be a sointer to a struct
stored in a back-end specific shared memory area which would be
accessed by the executor process at execution start. The backend
would destroy
Curtis Faith wrote:
The current transaction/user state seems to be stored in process
global space. This could be changed to be a sointer to a struct
stored in a back-end specific shared memory area which would be
accessed by the executor process at execution start. The backend
would
On Sun, 2002-10-06 at 11:46, Tom Lane wrote:
I can't personally get excited about something that only helps if your
server is starved for RAM --- who runs servers that aren't fat on RAM
anymore? But give it a shot if you like. Perhaps your analysis is
pessimistic.
snipped I don't
Hello to all the Doers of Postgres!!!
Last time I went through forums, people spoke highly about 7.3 and its capability to
do hot backups. My problem is if the database goes down and I lose my main data store,
then I will lose all transactions back to the time I did the pg_dump.
Other
I wrote:
That says that the best possible throughput on this test scenario is 5
transactions per disk rotation --- the CPU is just not capable of doing
more. I am actually getting about 4 xact/rotation for 10 or more
clients (in fact it seems to reach that plateau at 8 clients, and be
close
Sandeep Chadha [EMAIL PROTECTED] writes:
Postgresql has been lacking this all along. I've installed postgres
7.3b2 and still don't see any archive's flushed to any other
place. Please let me know how is hot backup procedure implemented in
current 7.3 beta(2) release.
AFAIK no such hot backup
Tom, first of all, excellent job improving the current algorithm. I'm glad
you look at the WALCommitLock code.
This must be so because the backends that are
released at the end of any given disk revolution will not be able to
participate in the next group commit, if there is already at least
Marc G. Fournier writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?
Probably not, because the version number needs to be changed and they need
to be rebuilt for each release.
--
Peter Eisentraut [EMAIL PROTECTED]
Hmmm, Then are there any new enhancements as far as backups are concerned between
current 7.2.x to 7.3.x.
Like can we do a tar when database is up and running or another feature.
Thanks a bunch in advance.
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]]
Sent: Monday,
Curtis Faith [EMAIL PROTECTED] writes:
Even the theoretical limit you mention of one transaction per revolution
per committing process seem like a significant bottleneck.
Well, too bad. If you haven't gotten your commit record down to disk,
then *you have not committed*. This is not
Curtis Faith wrote:
Good points.
Now for some surprising news (at least it surprised me).
I researched the file system source on my system (FreeBSD 4.6) and found
that the behavior was optimized for non-database access to eliminate
unnecessary writes when temp files are created and
On Tue, 2002-10-08 at 00:12, Curtis Faith wrote:
Tom, first of all, excellent job improving the current algorithm. I'm glad
you look at the WALCommitLock code.
This must be so because the backends that are
released at the end of any given disk revolution will not be able to
participate
This is the trickle syncer. It prevents bursts of disk activity every
30 seconds. It is for non-fsync writes, of course, and I assume if the
kernel buffers get low, it starts to flush faster.
AFAICT, the syncer only speeds up when virtual memory paging fills the
buffers past
a threshold and
On Tue, 2002-10-08 at 01:27, Tom Lane wrote:
The scheme we now have (with my recent patch) essentially says that the
commit delay seen by any one transaction is at most two disk rotations.
Unfortunately it's also at least one rotation :-(, except in the case
where there is no contention, ie,
Well, too bad. If you haven't gotten your commit record down to disk,
then *you have not committed*. This is not negotiable. (If you think
it is, then turn off fsync and quit worrying ;-))
I've never disputed this, so if I seem to be suggesting that, I've beee
unclear. I'm just assuming
On Mon, 2002-10-07 at 16:06, Curtis Faith wrote:
Well, too bad. If you haven't gotten your commit record down to disk,
then *you have not committed*. This is not negotiable. (If you think
it is, then turn off fsync and quit worrying ;-))
At this point, I think we've come full circle.
Greg Copeland wrote:
snip
If so, I assume it would become a configure option (--with-aio)?
Or maybe a GUC use_aio ?
:-)
Regards and best wishes,
Justin Clift
Regards,
Greg
On Mon, 2002-10-07 at 15:28, Bruce Momjian wrote:
This is the trickle syncer. It prevents bursts of disk activity every
30 seconds. It is for non-fsync writes, of course, and I assume if the
kernel buffers get low, it starts to flush faster.
Doesn't this also increase the likelihood that
Curtis Faith [EMAIL PROTECTED] writes:
Well, too bad. If you haven't gotten your commit record down to disk,
then *you have not committed*. This is not negotiable. (If you think
it is, then turn off fsync and quit worrying ;-))
I've never disputed this, so if I seem to be suggesting that,
Well, I was thinking that aio may not be available on all platforms,
thus the conditional compile option. On the other hand, wouldn't you
pretty much want it either on or off for all instances? I can see that
it would be nice for testing though. ;)
Greg
On Mon, 2002-10-07 at 16:23, Justin
On Mon, Oct 07, 2002 at 09:22:38PM +0200, Peter Eisentraut wrote:
Tom Lane writes:
But the source distribution hasn't *got* any binary files.
There are some under doc/src/graphics, and then there are
doc/postgres.tar.gz and doc/man.tar.gz.
And what about publishing xdelta patches?
--
I may be missing something obvious, but I don't see a way to get more
than 1 trx/process/revolution, as each previous transaction in that
process must be written to disk before the next can start, and the only
way it can be written to the disk is when the disk heads are on the
right place
I noticed that the new EXECUTE statement does not call SetQuerySnapshot,
which seems like a bad thing. The omission is masked by the defensive
code in CopyQuerySnaphot, which will automatically do SetQuerySnapshot
if it hasn't been done yet in the current transaction. However, this
doesn't
I sent this yesterday, but it seems not to have made it to the list...
I have a couple of comments orthogonal to the present discussion.
1) It would be fairly easy to write log records over a network to a
dedicated process on another system. If the other system has an
uninterruptible
Greg Copeland [EMAIL PROTECTED] writes:
Doesn't this also increase the likelihood that people will be
running in a buffer-poor environment more frequently that I
previously asserted, especially in very heavily I/O bound
systems? Unless I'm mistaken, that opens the door for a
general
Greg Copeland [EMAIL PROTECTED] writes:
Doesn't this also increase the likelihood that people will be running in
a buffer-poor environment more frequently that I previously asserted,
especially in very heavily I/O bound systems? Unless I'm mistaken, that
opens the door for a general case of
Curtis Faith wrote:
This is the trickle syncer. It prevents bursts of disk activity every
30 seconds. It is for non-fsync writes, of course, and I assume if the
kernel buffers get low, it starts to flush faster.
AFAICT, the syncer only speeds up when virtual memory paging fills the
On 7 Oct 2002 at 11:21, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I say if it's a char field, there should be no indicator of length as
it's not required. Just store those many characters straight ahead..
Your assumption fails when considering UNICODE or other
On 7 Oct 2002 at 13:48, Neil Conway wrote:
Sandeep Chadha [EMAIL PROTECTED] writes:
Postgresql has been lacking this all along. I've installed postgres
7.3b2 and still don't see any archive's flushed to any other
place. Please let me know how is hot backup procedure implemented in
67 matches
Mail list logo