From: ITAGAKI Takahiro [EMAIL PROTECTED]
You were running the test on the very memory-depend machine.
shared_buffers = 4GB / The scaling factor is 50, 800MB of data.
Thet would be why the patch did not work. I tested it with DBT-2,
10GB of
data and 2GB of memory. Storage is always the main
On Wed, Dec 20, 2006 at 08:44:07PM -0500, D'Arcy J.M. Cain wrote:
On Thu, 12 Oct 2006 14:24:22 -0400
D'Arcy J.M. Cain darcy@druid.net wrote:
On Thu, 12 Oct 2006 14:17:33 -0400
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain darcy@druid.net writes:
Cool. So what do I do with the
On Wed, 20 Dec 2006 17:49:15 +0100, Kaare Rasmussen [EMAIL PROTECTED] wrote:
I'm not sure, but as far as I remember, it will be a short release cycle
for
8.3 in order to finish some big items that couldn't be ready in time for
8.2.
But which items are more or less expected for 8.3? I
Takayuki Tsunakawa [EMAIL PROTECTED] wrote:
If you use Linux, it has very unpleased behavior in fsync(); It locks all
metadata of the file being fsync-ed. We have to wait for the completion of
fsync when we do read(), write(), and even lseek().
Oh, really, what an evil fsync is! Yes, I
To: Takayuki Tsunakawa [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Thursday, December 21, 2006 6:46 PM
Subject: Re: [HACKERS] Load distributed checkpoint
From: ITAGAKI Takahiro [EMAIL PROTECTED]
Takayuki Tsunakawa [EMAIL PROTECTED] wrote:
Oh, really, what an evil fsync is! Yes,
On Thu, Dec 21, 2006 at 06:46:36PM +0900, ITAGAKI Takahiro wrote:
Oh, really, what an evil fsync is! Yes, I sometimes saw a backend
waiting for lseek() to complete when it committed. But why does the
backend which is syncing WAL/pg_control have to wait for syncing the
data file? They
For 8.3 my goal is to improve the performance of single row operations,
such as
INSERT INTO foo ... VALUES (...)
UPDATE foo SET WHERE unique index = values
DELETE FROM foo WHERE unique index = values
OLTP Assumptions
- all statements are prepared first, then
On Thu, 21 Dec 2006 00:21:08 -0800
David Fetter [EMAIL PROTECTED] wrote:
On Wed, Dec 20, 2006 at 08:44:07PM -0500, D'Arcy J.M. Cain wrote:
Now that 8.3 has been branched shall I go ahead and commit? As
discussed I will put the currency symbol back in just so that it can
be discussed and
You were running the test on the very memory-depend machine.
shared_buffers = 4GB / The scaling factor is 50, 800MB of data.
Thet would be why the patch did not work. I tested it with DBT-2,
10GB of
data and 2GB of memory. Storage is always the main part of
performace here,
even not in
Simon Riggs wrote:
For 8.3 my goal is to improve the performance of single row operations,
Great. That's something that's useful across the board.
Currently, I'm aware of these possibilities, some fairly vague
...
- avoid RI checks for update of a column not mentioned in SET
Linked at
Russell Smith wrote:
I thought the plan was to change the ALTER TABLE command to allow vacuum
settings to be set.
That is my understanding too.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Richard Huxton wrote:
Simon Riggs wrote:
- improve RI check perf by caching small, static tables in each backend
- apply index filter conditions on index scan to avoid heap lookup
For fkey checks against a basically static table could you get away with
just checking the index and not the
I'm not sure how much you can do with typing. Things like heap_getattr
are macros, and thus untyped. Most places use attr as an index to an
array, which also can't be type checked.
If you switched everything over to inline functions you might
get it to
work, but that's about it.
IMHO
On Thu, 2006-12-21 at 09:36 -0500, Matthew O'Connor wrote:
Richard Huxton wrote:
Simon Riggs wrote:
- improve RI check perf by caching small, static tables in each backend
- apply index filter conditions on index scan to avoid heap lookup
For fkey checks against a basically static
On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote:
On the other hand, this would be the only part of the system where
the official interface/API is a system catalog table. Do we really
want to expose the internal representation of something as our API?
That doesn't seem wise to me...
Hi,
In PostgreSQL 8.2, log_statement display actual parameters value which is
very neat as in
DETAIL: parameters: $1 = '1', $2 = NULL
Currently I used log_statement='all' to display all statements and their
parameters but
that produced a lot of output and I am really only interested in the
JEAN-PIERRE PELLETIER [EMAIL PROTECTED] writes:
Is it possible to set log_min_error_statement to display the parameters
value?
No --- displaying the parameter values requires being able to run
user-defined output functions, which we can't do in an already-failed
transaction.
Zeugswetter Andreas ADI SD wrote:
I'm not sure how much you can do with typing. Things like heap_getattr
are macros, and thus untyped. Most places use attr as an index to an
array, which also can't be type checked.
If you switched everything over to inline functions you might
get it to
work,
Stephen Frost [EMAIL PROTECTED] writes:
I havn't built a reliable test case yet but I *think* the tuple
concurrently updated problem is with an analyze being run inside of a
function and also being run by autovacuum.
If so it should be fixed as of 8.2 --- I believe we changed the locking
rules
On Thu, Dec 21, 2006 at 10:27:12AM -0500, Andrew Dunstan wrote:
Um, surely you meant offset the physical numbers. Imho the logical
numbers
need to stay 1-n, because those numbers are used way more often and are
more user visible than the physical.
I don't think we should expose the
D'Arcy J.M. Cain darcy@druid.net writes:
Very good points. However, like the currency symbol issue I would like
to separate that into another discussion. The code already exists with
the warts you mention (and more) and this proposal is to fix one thing
that will make it more useful to
Martijn van Oosterhout kleptog@svana.org writes:
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the physical
index, not the logical one, for example.
Really? To me that's one of a large number of questions that
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I havn't built a reliable test case yet but I *think* the tuple
concurrently updated problem is with an analyze being run inside of a
function and also being run by autovacuum.
If so it should be fixed as of
Simon Riggs wrote:
On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote:
On the other hand, this would be the only part of the system where
the official interface/API is a system catalog table. Do we really
want to expose the internal representation of something as our API?
That doesn't
[EMAIL PROTECTED] (Tom Lane) writes:
Chris Browne [EMAIL PROTECTED] writes:
We're getting a bit of an anomaly relating to pg_stat_activity...
...
That PID has been dead for several days, but this connection is marked
as being open, still, after lo many days.
This probably just means that
I don't think we should expose the offset to user view at all - this
is
just for internal use, no?
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the
physical
index, not the logical one, for example. We
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the physical
index, not the logical one, for example.
On Thu, Dec 21, 2006 at 05:06:53PM +0100, Zeugswetter Andreas ADI SD wrote:
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the
physical index, not the logical one, for example. We don't want
rearranging columns
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
Really? To me that's one of a large number of questions that are
unresolved about how we'd do this. You can make a case for either
choice in quite a number of places.
Can we? For
The thing is, physical index numbers has meaning, the logical
index
number does not. In a view definition we're going to store the
physical index, not the logical one, for example. We don't want
rearranging columns to invalidate view definitions or plans.
I think we lack a
On Wed, Dec 20, 2006 at 5:33 AM, in message
[EMAIL PROTECTED],
Russell Smith [EMAIL PROTECTED] wrote:
The 8.1 documentation for ALTER TABLE states the following.
Adding a column with a non-null default or changing the type of an
existing column will require the entire table to be
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
Really? To me that's one of a large number of questions that are
unresolved about how we'd do this. You can make a case for either
choice in quite a number of
Chris Browne [EMAIL PROTECTED] writes:
There isn't any way, short of restarting the postmaster, to get rid of
that PID, is there?
The entry will get overwritten when that BackendId slot gets re-used,
so just starting enough concurrent backends should do it. (Since
incoming backends always take
Bruce Momjian wrote:
[1] http://developer.postgresql.org/index.php/Todo:WishlistFor83
That looks helpful.
Ok good :)
Seriously though, please slap me when things are wrong, not assigned yet
to the correct person .. there was a bit of guess work involved with
some of the points ..
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
You could make a case that we need *three* numbers: a permanent column
ID, a display position, and a storage position.
Could this not be handled by some catalog fixup after an add/drop? If we
get the having 3 numbers you will almost
On Thu, Dec 21, 2006 at 11:15:38AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Can we? For anything of any permenence (view definitions, rules,
compiled functions, plans, etc) you're going to want the physical
number, for the same reason we store the oids of
On Thu, 21 Dec 2006 10:47:52 -0500
Tom Lane [EMAIL PROTECTED] wrote:
D'Arcy J.M. Cain darcy@druid.net writes:
Very good points. However, like the currency symbol issue I would like
to separate that into another discussion. The code already exists with
the warts you mention (and more) and
The paper is a good one, from my perspective. It does address important
issues and maybe we don't all agree on the exact places lines have been
drawn, but I think we probably do agree that these things need to be
said. Now that they have been said, we must allow reasonable time for
the
Lukas Kahwe Smith wrote:
Bruce Momjian wrote:
[1] http://developer.postgresql.org/index.php/Todo:WishlistFor83
That looks helpful.
Ok good :)
Seriously though, please slap me when things are wrong, not assigned
yet to the correct person .. there was a bit of guess work involved
with
Martijn van Oosterhout kleptog@svana.org writes:
I was envisiging the physical number to be fixed and immutable (ie
storage position = permanent position).
There are two different problems being discussed here, and one of them
is insoluble if we take that position: people would like the system
Tom Lane wrote:
Actually, the more I think about it the more I think that 3 numbers
might be the answer. 99% of the code would use only the permanent ID.
Display position would be used in *exactly* one place, namely while
expanding SELECT foo.* --- I can't think of any other part of the
backend
How about...
ALTER TABLE ...
ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ]
ALTER AUTOANALYZE [ THRESHOLD | SCALE ]
... or would that create a whole bunch of reserved words?
On Dec 21, 2006, at 10:04 AM, Simon Riggs wrote:
On Wed, 2006-12-20 at 09:47 -0500, Jim Nasby wrote:
Jim Nasby [EMAIL PROTECTED] writes:
How about...
ALTER TABLE ...
ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ]
ALTER AUTOANALYZE [ THRESHOLD | SCALE ]
... or would that create a whole bunch of reserved words?
The way to predict when you're going to run into conflicts
Jim Nasby wrote:
How about...
ALTER TABLE ...
ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ]
ALTER AUTOANALYZE [ THRESHOLD | SCALE ]
Given these remarks from Tom:
Where we are currently at is experimenting to find
out what autovacuum's control knobs ought to be. The
0.9 doesn't apply cleanly after Peter's changes, so, new version
http://www.sigaev.ru/misc/user_defined_typmod-0.10.gz
Teodor Sigaev wrote:
Perhaps an array of int4 would be better? How much
Done
http://www.sigaev.ru/misc/user_defined_typmod-0.9.gz
The patch needs more cleanup before
Gregory Stark wrote:
Jim Nasby [EMAIL PROTECTED] writes:
How about...
ALTER TABLE ...
ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ]
ALTER AUTOANALYZE [ THRESHOLD | SCALE ]
... or would that create a whole bunch of reserved words?
The way to predict when you're going to
patch: http://www.sigaev.ru/misc/tsearch_core-0.27.gz
http://www.sigaev.ru/misc/tsearch_core-0.28.gz
new version, because of XML commit - old patch doesn't apply cleanly.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
Peter Eisentraut wrote:
Log Message:
---
Initial SQL/XML support: xml data type and initial set of functions.
this seems to cause regression failures on all the buildfarm members
(none of them are yet building with xml support).
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Stefan Kaltenbrunner wrote:
Peter Eisentraut wrote:
Log Message:
---
Initial SQL/XML support: xml data type and initial set of
functions.
this seems to cause regression failures on all the buildfarm members
Should be fixed now. I don't know why that one file was outdated.
--
Worky == Worky Workerson [EMAIL PROTECTED] writes:
Worky I was looking at upgrading to 8.2, but I make extensive use of
Worky the IP4 module.
The needed changes to ip4r to build on 8.2 are already in its CVS, and
as far as I know works, the only reason I've not done another release
yet is
I created a CMD_UTILITY, which upon being executed by the user should do the
following atomically:
1- drops a table
2- deletes from another table all rows with a certain criterion: DELETE
FROM pg_t1 WHERE att = val
3- deletes from a third table all rows with a certain criterion: DELETE
FROM
Ehab Galal wrote:
I created a CMD_UTILITY, which upon being executed by the user should do
the following atomically:
1- drops a table
2- deletes from another table all rows with a certain criterion: DELETE
FROM pg_t1 WHERE att = val
3- deletes from a third table all rows with a certain
Lukas Kahwe Smith wrote:
Bruce Momjian wrote:
[1] http://developer.postgresql.org/index.php/Todo:WishlistFor83
That looks helpful.
Ok good :)
Seriously though, please slap me when things are wrong, not assigned yet
to the correct person .. there was a bit of guess work involved
- Original Message -
From: Zeugswetter Andreas ADI SD [EMAIL PROTECTED]
To: Takayuki Tsunakawa [EMAIL PROTECTED]; ITAGAKI
Takahiro [EMAIL PROTECTED]
Yes, I used half the size of RAM as the shared buffers, which is
reasonable. And I cached all the data.
For pg, half RAM for
On Tue, Dec 19, 2006 at 6:13 PM, in message
[EMAIL PROTECTED], Bruce Momjian
[EMAIL PROTECTED] wrote:
if the company dies, the community keeps going (as it did after
Great
Bridge, without a hickup), but if the community dies, the company
dies
too.
This statement seems to ignore
On Wed, Dec 20, 2006 at 6:05 AM, in message
[EMAIL PROTECTED], Takayuki Tsunakawa
[EMAIL PROTECTED] wrote:
I consider that smoothing the load (more meaningfully, response
time)
has higher priority over checkpoint punctuality in a practical
sense,
because the users of a system benefit from
Tom Lane [EMAIL PROTECTED] writes:
Actually, the more I think about it the more I think that 3 numbers
might be the answer. 99% of the code would use only the permanent ID.
Don't we already have such a permanent number -- just one we don't use
anywhere in the data model? Namely the oid of the
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Actually, the more I think about it the more I think that 3 numbers
might be the answer. 99% of the code would use only the permanent ID.
Don't we already have such a permanent number -- just one we don't use
Kevin Grittner [EMAIL PROTECTED] wrote:
I consider that smoothing the load (more meaningfully, response time)
has higher priority over checkpoint punctuality in a practical sense,
I agree with that.
I agree with checkpoint_time is not so important, but we should
respect
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Tom Lane) wrote:
Chris Browne [EMAIL PROTECTED] writes:
There isn't any way, short of restarting the postmaster, to get rid of
that PID, is there?
The entry will get overwritten when that BackendId slot gets re-used,
so just
Hello, Mr. Grittner,
From: Kevin Grittner [EMAIL PROTECTED]
We have 3,000 directly connected users, various business partner
interfaces, and public web entry doing OLTP in 72 databases
distributed
around the state, with real-time replication to central databases
which
are considered derived
Takayuki Tsunakawa [EMAIL PROTECTED] wrote:
For pg, half RAM for shared_buffers is too much. The ratio is good for
other db software, that does not use the OS cache.
What percentage of RAM is recommended for shared buffers in general?
40%? 30%? Or, is the general recommendation like
quote
Companies often bring fresh prespective, ideas, and testing
infrastucture to a project.
/quote
prespective || perspective ?
g.-
On 12/21/06, Kevin Grittner [EMAIL PROTECTED] wrote:
On Tue, Dec 19, 2006 at 6:13 PM, in message
[EMAIL PROTECTED], Bruce Momjian
[EMAIL PROTECTED] wrote:
On Dec 21, 2006, at 1:28 PM, Andrew Dunstan wrote:
Jim Nasby wrote:
How about...
ALTER TABLE ...
ALTER AUTOVACUUM [ THRESHOLD | SCALE | COST DELAY | COST LIMIT ]
ALTER AUTOANALYZE [ THRESHOLD | SCALE ]
Given these remarks from Tom:
Where we are currently at is experimenting to find
out
Hello, Itagaki-san,
Thank you for an interesting piece of information.
From: ITAGAKI Takahiro [EMAIL PROTECTED]
If you use linux, try the following settings:
1. Decrease /proc/sys/vm/dirty_ratio and dirty_background_ratio.
2. Increase wal_buffers to redule WAL flushing.
3. Set
Jim Nasby [EMAIL PROTECTED] writes:
The only other thought that comes to mind is that such syntax will
make it a *lot* more verbose to set all the options for a table.
Which should surely make you wonder whether setting these options
per-table is the most important thing to do...
Arguing
On Wed, 20 Dec 2006, Inaam Rana wrote:
Talking of bgwriter_* parameters I think we are missing a crucial
internal counter i.e. number of dirty pages. How much work bgwriter has
to do at each wakeup call should be a function of total buffers and
currently dirty buffers.
This is actually a
From: Takayuki Tsunakawa [EMAIL PROTECTED]
(5) (4) + /proc/sys/vm/dirty* tuning
dirty_background_ratio is changed from 10 to 1, and dirty_ratio is
changed from 40 to 4.
308 349 84 349 84
Sorry, I forgot to include the result when using Itagaki-san's patch.
The patch showd the following
On 12/22/06, Takayuki Tsunakawa [EMAIL PROTECTED] wrote:
From: Takayuki Tsunakawa [EMAIL PROTECTED]
(5) (4) + /proc/sys/vm/dirty* tuning
dirty_background_ratio is changed from 10 to 1, and dirty_ratio is
changed from 40 to 4.
308 349 84 349 84
Sorry, I forgot to include the result
Hello,
I see las actualisation from 18. december
regards
Pavel Stehule
_
Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/
---(end of broadcast)---
TIP 5: don't
70 matches
Mail list logo
