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
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" wrote:
> > On Thu, 12 Oct 2006 14:17:33 -0400
> > Tom Lane <[EMAIL PROTECTED]> wrote:
> > > "D'Arcy J.M. Cain" writes:
> > > > Cool. So what do I do with the patch? Should
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?
"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
To: "Takayuki Tsunakawa" <[EMAIL PROTECTED]>
Cc:
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, I sometimes s
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?
For 8.3 my goal is to improve the performance of single row operations,
such as
INSERT INTO foo ... VALUES (...)
UPDATE foo SET WHERE =
DELETE FROM foo WHERE =
OLTP Assumptions
- all statements are prepared first, then executed with bound
parameters.
- need to
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 discusse
> > 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,
> > ev
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 lea
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 tabl
> 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.
>
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
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, b
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
r
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
"D'Arcy J.M. Cain" 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 others. Let's
Martijn van Oosterhout 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 are
unresolved ab
* 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 fixe
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 seem
[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 m
> > 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.
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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?
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
Martijn van Oosterhout 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 anything of an
> > > 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 w
>>> 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 t
Tom Lane wrote:
Martijn van Oosterhout 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.
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 t
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 .. especial
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
On Thu, Dec 21, 2006 at 11:15:38AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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 functions and t
On Thu, 21 Dec 2006 10:47:52 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> "D'Arcy J.M. Cain" 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
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 understandin
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 some
Martijn van Oosterhout 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 to
automatically
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
backen
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 c
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 catal
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 t
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
Ste
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 outd
> "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
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 cert
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 wo
- 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
>>> 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 org
>>> 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 b
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
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 checkpo
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
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
"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 recommendati
"Companies often bring fresh prespective, ideas, and testing
infrastucture to a project."
"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 what
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 wal_
"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...
Arguin
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 que
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 fol
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
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
