Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
The advantage of using a counter instead of a simple active
bit is that buffers that are (or have been) used heavily will be able to
go through several sweeps of the clock before being freed. Infrequently
used buffers (such as those from a
When I try to input a unicode caracter which code is greater than
U+2, phpPgAdmin returns the following error message :
ERROR: Unicode characters greater than or equal to 0x1 are not
supported
Could someone fix this problem ?
If yes, would you please tell me where can i download the
And most databases get a mix of updates and selects. I would expect it would
be pretty hard to go that long with any significant level of update activity
and no vacuums and not notice the performance problems from the dead tuples.
I think the people who've managed to shoot themselves in the foot
Some SQL constructs will be satisfied before all rows of a set has been
examined. I'm thinking of for instance:
EXISTS(SELECT * FROM y WHERE y.a 0)
If the first row of collection y fulfills the WHERE predicate, there's
no reason to continue perusing the rest of the rows. Now, what if 'y' is
a
It looks like the code that handles returning a RECORD variable doesn't
cope with dropped columns in the function result rowtype.
(If you instead declare rec as usno%rowtype, you get a different set
of misbehaviors after adding/dropping columns, so that code path isn't
perfect either :-()
Isn't it
... c) would be very bad since it
doesn't give me any chance to release the resources that
where used in order to produce the rows.
You are supposed to free resources used to produce the rows before
srf_return_next();
The actual rows are pfree()'d by pg. (an dso are any other palloc()'d
Hi,
looking for the way how to increase performance at Windows XP
box, I found the parameters
#fsync = true # turns forced
synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
# fsync,
John,
You are supposed to free resources used to produce the rows before srf_return_next();
I can (and must) free up the resources used to produce one single row at
that time yes, but I might have resources that is common to all rows.
Let's assume that I have a file open for instance. I read
Would there be any value in incrementing by 2 for index accesses and 1
for seq-scans/vacuums? Actually, it should probably be a ratio based on
random_page_cost shouldn't it?
What happens with very small hot tables that are only a few pages and thus have
no index defined.
I think it would
Gaetano Mendola [EMAIL PROTECTED] writes:
We do ~4000 txn/minute so in 6 month you are screewd up...
Sure, but if you ran without vacuuming for 6 months, wouldn't you notice
the
huge slowdowns from all those dead tuples before that?
I would think that only applies to databases where
Things worth experimenting with (these are all untested, so please
report any successes):
1) Try reformatting with a cluster size of 8Kb (the pg page size), if
you can.
What about recompiling pg with a 4k block size. Win32 file cluster
sizes and memory allocation units are both on 4k
The general question is - does PostgreSQL really need fsync? I suppose it
is a question for design, not platform-specific one. It sounds like only
one scenario, when fsync is useful, is to interprocess communication via
open file. But PostgreSQL utilize IPC for this, so does fsync is really
On Thu, 17 Feb 2005, Magnus Hagander wrote:
Hi,
looking for the way how to increase performance at Windows XP
box, I found the parameters
#fsync = true # turns forced
synchronization on or off
#wal_sync_method = fsync# the default varies across platforms:
On Thu, 17 Feb 2005, Christopher Kings-Lynne wrote:
The general question is - does PostgreSQL really need fsync? I suppose it
is a question for design, not platform-specific one. It sounds like only
one scenario, when fsync is useful, is to interprocess communication via
open file. But PostgreSQL
On Thu, 17 Feb 2005 17:54:38 +0300 (MSK)
E.Rodichev [EMAIL PROTECTED] wrote:
On Thu, 17 Feb 2005, Christopher Kings-Lynne wrote:
The general question is - does PostgreSQL really need fsync? I
suppose it is a question for design, not platform-specific one. It
sounds like only one scenario,
E.Rodichev [EMAIL PROTECTED] writes:
On Thu, 17 Feb 2005, Christopher Kings-Lynne wrote:
Fsync is so that when your computer loses power without warning, you
will have no data loss.
If you turn it off, you run the risk of losing data if you lose power.
Chris
This problem is addressed by
E.Rodichev wrote:
This problem is addressed by file system (fsck, journalling etc.).
Is it reasonable to handle it directly within application?
In the words of the Duke of Wellington, If you believe that you'll
believe anything.
Please review past discussions on the mailing lists on this
In [EMAIL PROTECTED], on 02/17/05
at 10:21 AM, Andrew Dunstan [EMAIL PROTECTED] said:
E.Rodichev wrote:
This problem is addressed by file system (fsck, journalling etc.).
Is it reasonable to handle it directly within application?
In the words of the Duke of Wellington, If you believe
Thomas Hallgren [EMAIL PROTECTED] writes:
My question is, what happens when the evaluator doesn't need more rows?
Will it:
a) call the function with call_cntr = max_calls?
b) continue calling until the set is exhausted anyway?
c) simply stop calling?
(c)
a) seems unlikely since max_calls
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
My question is, what happens when the evaluator doesn't need more rows?
Will it:
a) call the function with call_cntr = max_calls?
b) continue calling until the set is exhausted anyway?
c) simply stop calling?
(c)
a) seems
So by all means turn off fsync if you want the performance gain *and*
you accept the risk. But if you do, don't come crying later that your
data has been lost or corrupted.
(the results are interesting, though - with fsync off Windows
and Linux
are in the same performance ballpark.)
Yes,
This is what we have discovered. AFAIK, all other major databases or
other similar apps (like exchange or AD) all open files with
FILE_FLAG_WRITE_THROUGH and do *not* use fsync. It might
give noticably
better performance with an O_DIRECT style WAL logging at
least. But I'm
unsure if the
Magnus Hagander [EMAIL PROTECTED] writes:
This is what we have discovered. AFAIK, all other major databases or
other similar apps (like exchange or AD) all open files with
FILE_FLAG_WRITE_THROUGH and do *not* use fsync. It might give noticably
better performance with an O_DIRECT style WAL
Things worth experimenting with (these are all untested, so please
report any successes):
1) Try reformatting with a cluster size of 8Kb (the pg page size), if
you can.
2) Disable the last access time (like noatime on linux). fsutil
behavior set disablelastaccess 1
3) Disable 8.3 filenames
On Thu, 17 Feb 2005, Andrew Dunstan wrote:
(the results are interesting, though - with fsync off Windows and Linux are
in the same performance ballpark.)
Some addition:
WinXP fsync = true 20-28 tps
WinXP fsync = false 600 tps
Linux fsync = true 800 tps
Linux fsync = false
Doesn't Windows support O_SYNC (or even better O_DSYNC) flag
to open()?
That should be the Posixy spelling of FILE_FLAG_WRITE_THROUGH, if the
latter means what I suppose it does.
They should, but someone said it didn't work. I haven't
followed up on it, though, so it is quite possible it works.
Doesn't Windows support O_SYNC (or even better O_DSYNC) flag to
open()?
That should be the Posixy spelling of FILE_FLAG_WRITE_THROUGH, if the
latter means what I suppose it does.
They should, but someone said it didn't work. I haven't followed up on
it, though, so it is quite possible it
Magnus Hagander [EMAIL PROTECTED] writes:
Oh, and finally. The win32 commands have the following options:
FILE_FLAG_NO_BUFFERING. This disables the cache completely. It also has
lots of limits, like every read and write has to be on a sector boundary
etc. It gives great performance with async
Some addition:
WinXP fsync = true 20-28 tps
WinXP fsync = false 600 tps
Linux fsync = true 800 tps
Linux fsync = false 980 tps
Wow, that's terrible on Windows. If there's a solution, it'd be nice to
backport it...
Chris
---(end of
There are two different concerns here.
1. transactions loss because of unexpected power loss and/or system failure
2. inconsistent database state
For many application (1) is fairly acceptable, and (2) is not.
So I'd like to formulate my questions by another way.
- if PostgeSQL is running without
WinXP fsync = true 20-28 tps
WinXP fsync = false 600 tps
Linux fsync = true 800 tps
Linux fsync = false 980 tps
Wow, that's terrible on Windows. If there's a solution, it'd be nice
to
backport it...
there is. I just rigged up a test benchmark comparing sync
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
WinXP fsync = true 20-28 tps
WinXP fsync = false 600 tps
Linux fsync = true 800 tps
Linux fsync = false 980 tps
Wow, that's terrible on Windows. If there's a solution, it'd be nice to
backport it...
Actually, the
Evgeny Rodichev wrote:
There are two different concerns here.
1. transactions loss because of unexpected power loss and/or system failure
2. inconsistent database state
For many application (1) is fairly acceptable, and (2) is not.
So I'd like to formulate my questions by another way.
- if
WinXP fsync = true 20-28 tps
WinXP fsync = false 600 tps
Linux fsync = true 800 tps
Linux fsync = false 980 tps
Wow, that's terrible on Windows. If there's a solution, it'd be nice
to
backport it...
there is. I just rigged up a test benchmark comparing sync
One point that I no longer recall the reasoning behind is that xlog.c
doesn't think O_SYNC is a preferable default over fsync. We'd
certainly
want to hack xlog.c to change its mind about that, at least on
Windows;
assuming that the FILE_FLAG way is indeed faster.
I also confirmed that the
Magnus Hagander [EMAIL PROTECTED] writes:
Tom, if you look at all the requirements of FILE_FLAG_NO_BUFFERING on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/
base/createfile.asp, can you say offhand if the WAL code fulfills them?
If I'm reading it right, you are
On Thu, 17 Feb 2005, Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
WinXP fsync = true 20-28 tps
WinXP fsync = false 600 tps
Linux fsync = true 800 tps
Linux fsync = false 980 tps
Wow, that's terrible on Windows. If there's a solution, it'd be nice to
Magnus Hagander [EMAIL PROTECTED] writes:
Tom, if you look at all the requirements of FILE_FLAG_NO_BUFFERING
on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/
base/createfile.asp, can you say offhand if the WAL code fulfills
them?
If I'm reading it right, you
Evgeny Rodichev [EMAIL PROTECTED] writes:
Any claimed TPS rate exceeding your disk drive's rotation rate is a
red flag.
Write cache is enabled under Linux by default all the time I make deal
with it (since 1993).
You're playing with fire.
fsync() really works fine as I switch off my
After multiple runs on different blocksizes( a few anomalous results
aside), I didn't see a whole lot of difference between
FILE_FLAG_NO_BUFFERING being on or off for writing performance.
However, with NO_BUFFERING set, the file is not *read* cached at all.
While the performance is on not terrible
Magnus Hagander [EMAIL PROTECTED] writes:
Is there actually a reason why we don't use O_DIRECT on Unix?
Portability, or rather the complete lack of it. Stuff that isn't in the
Single Unix Spec is a hard sell.
regards, tom lane
---(end of
Evgeny Rodichev wrote:
Write cache is enabled under Linux by default all the time I make deal
with it (since 1993).
It doesn't interfere with fsync(), as linux kernel uses cache flush for
fsync.
The problem is that most IDE drives lie (or perhaps you could say the
specification is ambiguous)
Magnus Hagander [EMAIL PROTECTED] writes:
Is there actually a reason why we don't use O_DIRECT on Unix?
Portability, or rather the complete lack of it. Stuff that isn't in
the
Single Unix Spec is a hard sell.
Well, how about this (ok, maybe I'm way out in left field):
Change fsync option
On Wed, 16 Feb 2005, Tom Lane wrote:
Richard Huxton dev@archonet.com writes:
I seem to remember some subtle problems with dropped columns and plpgsql
functions - could be one of those still left.
It looks like the code that handles returning a RECORD variable doesn't
cope with dropped
Oliver Jowett [EMAIL PROTECTED] writes:
So Linux is indeed doing a cache flush on fsync
Actually I think the root of the problem was precisely that Linux does not
issue any sort of cache flush commands to drives on fsync. There was some talk
on linux-kernel of what how they could take
Greg Stark wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
So Linux is indeed doing a cache flush on fsync
Actually I think the root of the problem was precisely that Linux does not
issue any sort of cache flush commands to drives on fsync. There was some talk
on linux-kernel of what how they
On Thu, 17 Feb 2005, Tom Lane wrote:
Evgeny Rodichev [EMAIL PROTECTED] writes:
Any claimed TPS rate exceeding your disk drive's rotation rate is a
red flag.
Write cache is enabled under Linux by default all the time I make deal
with it (since 1993).
You're playing with fire.
Yes. I'm lucky in
On Fri, 18 Feb 2005, Oliver Jowett wrote:
Evgeny Rodichev wrote:
Write cache is enabled under Linux by default all the time I make deal
with it (since 1993).
It doesn't interfere with fsync(), as linux kernel uses cache flush for
fsync.
The problem is that most IDE drives lie (or perhaps you could
On Fri, 17 Feb 2005, Greg Stark wrote:
Oliver Jowett [EMAIL PROTECTED] writes:
So Linux is indeed doing a cache flush on fsync
Actually I think the root of the problem was precisely that Linux does not
issue any sort of cache flush commands to drives on fsync.
No, it does. Let's try the simplest
Greg Stark wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
We do ~4000 txn/minute so in 6 month you are screewd up...
Sure, but if you ran without vacuuming for 6 months, wouldn't you notice the
huge slowdowns from all those dead tuples before that?
In my applications yes, for sure
Magnus Hagander [EMAIL PROTECTED]
news:[EMAIL PROTECTED]
This is what we have discovered. AFAIK, all other major databases or
other similar apps (like exchange or AD) all open files with
FILE_FLAG_WRITE_THROUGH and do *not* use fsync. It might give noticably
better performance with an
Evgeny Rodichev [EMAIL PROTECTED] writes:
No, it does. Let's try the simplest test:
for (i = 0; i LEN; i++) {
write (fd, buf, 512);
if (sync) fsync (fd);
}
with sync = 0 and 1, and you'll see the difference.
Uh, I'm sure you'll see a difference, one will be limited by the i/o
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
BTW, why not do an automatic vacuum instead of shutdown ? At least the
DB do not stop working untill someone study what the problem is and
how solve it.
No, the entire point of this discussion is to whup the DBA upside the
head
53 matches
Mail list logo
