On 2007-03-27, David Fetter [EMAIL PROTECTED] wrote:
Per further discussion with Andrew of Supernews and Merlin Moncure,
I've added a check for compound types and moved the creation of the
array type from DefineRelation in backend/commands/tablecmds.c to
heap_create_with_catalog in
On Tue, 2007-03-27 at 20:48 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems possible to reduce overall WAL volume by roughly 25% on common
workloads by optimising the way UPDATE statements generate WAL.
This seems a huge amount of work to optimize *one* benchmark.
On Wed, Mar 28, 2007 at 02:47:12PM +0900, ITAGAKI Takahiro wrote:
Magnus Hagander [EMAIL PROTECTED] wrote:
IIRC, we're still waiting for performance numbers showing there exists a
win from this patch.
Here is a performance number of Direct I/O support on Windows.
There was 10%+ of
On Wed, 2007-03-28 at 10:54 +0900, Koichi Suzuki wrote:
As written below, full page write can be
categolized as follows:
1) Needed for crash recovery: first page update after each checkpoint.
This has to be kept in WAL.
2) Needed for archive recovery: page update between pg_start_backup
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I would love, love, love to be able to use this syntax within pg_dump as
well, so we can create multiple indexes in parallel at restore time.
I can hardly conceive of greater folly than putting an *experimental*
psql facility into pg_dump
Hello,
I found in queue patch simply custom variables protection, Pavel Stehule
which you removed and didn't find my patch for scrollable cursors in
plpgsql.
Regards
Pavel Stehule
_
Emotikony a pozadi programu MSN Messenger
Josh Berkus wrote:
Bruce,
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that have are not ready for
review because they have not been completed by their authors.
Can you flag those somehow?
I have sent out email on every
Bruce Momjian [EMAIL PROTECTED] writes:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a significant number of patches that
On Wed, Mar 28, 2007 at 08:07:14AM +0100, Simon Riggs wrote:
On Tue, 2007-03-27 at 20:48 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems possible to reduce overall WAL volume by roughly 25% on common
workloads by optimising the way UPDATE statements generate WAL.
On Tue, 27 Mar 2007, Magnus Hagander wrote:
Would not at least some of these numbers be better presented through the
stats collector, so they can be easily monitored?
That goes along the line of my way way way away from finished attempt
earlier, perhaps a combination of these two patches?
Kenneth Marshall [EMAIL PROTECTED] writes:
We use DSPAM as one of our anti-spam options. Its UPDATE pattern is to
increment a spam counter or a not-spam counter while keeping the user and
token information the same. This would benefit from this optimization.
Would it? How wide is the user and
Kenneth Marshall wrote:
We use DSPAM as one of our anti-spam options. Its UPDATE pattern is to
increment a spam counter or a not-spam counter while keeping the user and
token information the same. This would benefit from this optimization.
Currently we are forced to use MySQL with MyISM tables
Kenneth Marshall [EMAIL PROTECTED] writes:
On Wed, Mar 28, 2007 at 09:46:30AM -0400, Tom Lane wrote:
Would it? How wide is the user and token information?
Sorry about the waste of time. I just noticed that the proposal is
only for rows over 128 bytes. The token definition is:
CREATE TABLE
Hi!
From what I can see, the ecpg thread tests (src/interfaces/ecpg/threads)
don't ever run. They rely on ENABLE_THREAD_SAFETY to be set, but even when
I build with --enable-thread-safety, it's not set. This is because ecpg
does not pull in pg_config.h, and also does not specify it on the
On Wed, 2007-03-28 at 15:51 +0200, Florian G. Pflug wrote:
BTW, the COMMIT NOWAIT feature Simon Riggs proposed should provide
a huge speedup too, since dspam runs one transaction for each token
it has to update.
I've switched to doing the COMMIT NOWAIT as a priority now, but do plan
to do
Tom Lane [EMAIL PROTECTED] writes:
Yeah, this illustrates my concern that the proposal is too narrowly
focused on a specific benchmark.
A lot of the recently proposed changes don't really fit in the optimizations
category very well at all. I think of them more as avoiding pitfalls.
Currently
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Yeah, this illustrates my concern that the proposal is too narrowly
focused on a specific benchmark.
A lot of the recently proposed changes don't really fit in the optimizations
category very well at all. I think of them more as
Gregory Stark [EMAIL PROTECTED] writes:
A lot of the recently proposed changes don't really fit in the
optimizations category very well at all. I think of them more as
avoiding pitfalls.
Well, we can't put a major amount of complexity into the system for
each possible pitfall.
This one is
Simon Riggs wrote:
On Tue, 2007-03-27 at 20:48 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
It seems possible to reduce overall WAL volume by roughly 25% on common
workloads by optimising the way UPDATE statements generate WAL.
This seems a huge amount of work to optimize
On Wed, 2007-03-28 at 10:51 -0400, Tom Lane wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
On Wed, Mar 28, 2007 at 09:46:30AM -0400, Tom Lane wrote:
Would it? How wide is the user and token information?
Sorry about the waste of time. I just noticed that the proposal is
only for rows
Tom Lane [EMAIL PROTECTED] writes:
Actually, PG does extremely well on that in the situation where the
static data is *really* wide, ie, wide enough to be toasted out-of-line.
Simon's proposal will only help for an intermediate range of situations
where the row is wide but not very wide.
Gregory Stark [EMAIL PROTECTED] writes:
The reason I think this is idea is exciting is that later I would suggest
applying it to HOT updates. Having to keep a spare tuple's worth of space in
every page is pretty annoying. But if we could get by with the average
half-tuple dead space to do an
If I change the code in one of the ecpg regression tests (porting tests as
well to non-pthread win32), am I supposed to manually change the .c files
in the expected directory? Or is ther some other process for it?
//Magnus
---(end of broadcast)---
I agree that these values need a second look. I think a
TOAST_TUPLE_THRESHOLD well smaller than the current value would
still
easily pay its way. With a little caution to avoid wasting too much
effort on the last few bytes I suspect even as low as
400-500 bytes is probably
On Tue, 2007-03-27 at 21:15 -0400, Bruce Momjian wrote:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a significant number
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes:
Btw: Do we consider the existance of toasted columns in the seq-scan
cost estimation ?
Not at present. There was some discussion of this but it seems like
a fair amount of work --- we don't currently track statistics on how
many of a
On 3/23/07, Pavan Deolasee [EMAIL PROTECTED] wrote:
Its slightly different for the HOT-chains created by this transaction
which
is creating the index. We should index the latest version of the row which
is not yet committed. But thats ok because when CREATE INDEX commits
this latest version
On Wed, Mar 28, 2007 at 07:05:24AM -, Andrew - Supernews wrote:
On 2007-03-27, David Fetter [EMAIL PROTECTED] wrote:
Per further discussion with Andrew of Supernews and Merlin
Moncure, I've added a check for compound types and moved the
creation of the array type from DefineRelation in
David Fetter wrote:
The first is in type_sanity, which basically doesn't understand that
complex types now have array types associated with them and thinks
they're orphan array types, so it's actually the test that's not
right.
Hmm, I question the usefulness of automatically creating array
In another thread I wrote:
... One thing I was just thinking about is that it's silly to have
the threshold constrained so strongly by a desire that tuples in toast
tables not be toastable. It would be trivial to tweak the heapam.c
routines so that they simply don't invoke the toaster when
On Wed, 2007-03-28 at 22:24 +0530, Pavan Deolasee wrote:
Just when I thought we have nailed down CREATE INDEX, I realized
that there something more to worry. The problem is with the HOT-chains
created by our own transaction which is creating the index. We thought
it will be enough to index
On Wed, Mar 28, 2007 at 06:13:03PM +0200, Magnus Hagander wrote:
If I change the code in one of the ecpg regression tests (porting tests as
well to non-pthread win32), am I supposed to manually change the .c files
in the expected directory? Or is ther some other process for it?
Just run the
Michael Meskes wrote:
On Wed, Mar 28, 2007 at 06:13:03PM +0200, Magnus Hagander wrote:
If I change the code in one of the ecpg regression tests (porting tests as
well to non-pthread win32), am I supposed to manually change the .c files
in the expected directory? Or is ther some other process
On Wed, 2007-03-28 at 11:17 -0400, Tom Lane wrote:
This one is similar, if you keep a bunch of static data attached to
some small dynamic data your WAL and table bloats.
Actually, PG does extremely well on that in the situation where the
static data is *really* wide, ie, wide enough to be
Alvaro Herrera wrote:
David Fetter wrote:
The first is in type_sanity, which basically doesn't understand that
complex types now have array types associated with them and thinks
they're orphan array types, so it's actually the test that's not
right.
Hmm, I question the usefulness of
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, I question the usefulness of automatically creating array types for
all relation types that are created -- the catalog bloat seems a bit too
much. An array of pg_autovacuum for example, does that make sense?
Not only that, it won't even work for
Tom Lane [EMAIL PROTECTED] writes:
I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
compiled-in parameters that are recorded in pg_control and checked for
compatibility at startup (like BLCKSZ) --- this will prevent anyone from
shooting themselves in the foot while
Simon Riggs wrote:
On Wed, 2007-03-28 at 22:24 +0530, Pavan Deolasee wrote:
Just when I thought we have nailed down CREATE INDEX, I realized
that there something more to worry. The problem is with the HOT-chains
created by our own transaction which is creating the index. We thought
it will be
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Couldn't you store the creating transaction's xid in pg_index, and
let other transaction check that against their snapshot like they
would for any tuple's xmin or xmax?
What snapshot? I keep having to
Florian G. Pflug [EMAIL PROTECTED] writes:
Couldn't you store the creating transaction's xid in pg_index, and
let other transaction check that against their snapshot like they
would for any tuple's xmin or xmax?
What snapshot? I keep having to remind people that system catalog
operations are
On 3/28/07, Simon Riggs [EMAIL PROTECTED] wrote:
Set it at the end, not the beginning.
At the end of what ? It does not help to set it at the end of CREATE
INDEX because the transaction may not commit immediately. In
the meantime, many new transactions may start with
transaction id
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Couldn't you store the creating transaction's xid in pg_index, and
let other transaction check that against their snapshot like they
would for any tuple's xmin or xmax?
What snapshot? I keep having to remind people that system
On Wed, Mar 28, 2007 at 01:33:56PM -0400, Andrew Dunstan wrote:
Alvaro Herrera wrote:
David Fetter wrote:
The first is in type_sanity, which basically doesn't understand
that complex types now have array types associated with them and
thinks they're orphan array types, so it's actually the
On Wed, 2007-03-28 at 23:42 +0530, Pavan Deolasee wrote:
On 3/28/07, Simon Riggs [EMAIL PROTECTED] wrote:
Set it at the end, not the beginning.
At the end of what ? It does not help to set it at the end of CREATE
INDEX because the transaction may not commit
Pavan Deolasee wrote:
On 3/28/07, Tom Lane [EMAIL PROTECTED] wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Couldn't you store the creating transaction's xid in pg_index, and
let other transaction check that against their snapshot like they
would for any tuple's xmin or xmax?
What
Tom Lane [EMAIL PROTECTED] writes:
CREATE ARRAY TYPE FOR foo
I also made a suggestion along the way that we never create array types
automatically except for domains. Ie, we don't need a new command, we just
document that what you do if you want to create an array of something is
create
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
CREATE ARRAY TYPE FOR foo
I also made a suggestion along the way that we never create array types
automatically except for domains.
That seems awfully strange, not to mention very non-backwards-compatible
since it
On Wed, Mar 28, 2007 at 03:24:26PM -0400, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
CREATE ARRAY TYPE FOR foo
I also made a suggestion along the way that we never create array
types automatically except for domains.
That seems awfully
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there are a
Simon Riggs wrote:
On Tue, 2007-03-27 at 21:15 -0400, Bruce Momjian wrote:
Right now, all the patches I think are ready for review are in the patch
queue:
http://momjian.postgresql.org/cgi-bin/pgpatches
However, with feature freeze coming on Sunday, I am worried because
there
at seems like a bit of a whacky criterion to use before reviewing a patch.
wacky?
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is ever
completed anyways.
It favors those who do not wait until the
Joshua D. Drake wrote:
at seems like a bit of a whacky criterion to use before reviewing a patch.
wacky?
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is
ever
completed anyways.
It
On Wed, 2007-03-28 at 15:48 -0400, Bruce Momjian wrote:
What about the delayed fsync patch?
All complete bar two fiddly items, as of Mar 11, design-to-complete
posted along with patch.
Working on those now.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
It's probably a good idea to have a queue of those too, to allow others
to finish them if the original author hasn't/can't/won't. I'm not sure
which ones you mean.
At this point, with four days left before feature freeze, if the
Magnus Hagander wrote:
Hi!
From what I can see, the ecpg thread tests (src/interfaces/ecpg/threads)
Uh, the directory src/interfaces/ecpg/threads doesn't exist. I assume
you mean src/interfaces/ecpg/test/thread.
don't ever run. They rely on ENABLE_THREAD_SAFETY to be set, but even when
I
Bruce Momjian wrote:
Magnus Hagander wrote:
Hi!
From what I can see, the ecpg thread tests (src/interfaces/ecpg/threads)
Uh, the directory src/interfaces/ecpg/threads doesn't exist. I assume
you mean src/interfaces/ecpg/test/thread.
Yes, that's what I mean. Sorry 'bout that.
don't
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
It's probably a good idea to have a queue of those too, to allow others
to finish them if the original author hasn't/can't/won't. I'm not sure
which ones you mean.
At this point, with four days left
Magnus Hagander wrote:
Bruce Momjian wrote:
Magnus Hagander wrote:
Hi!
From what I can see, the ecpg thread tests (src/interfaces/ecpg/threads)
Uh, the directory src/interfaces/ecpg/threads doesn't exist. I assume
you mean src/interfaces/ecpg/test/thread.
Yes, that's what I
On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote:
they
It would be good to know who/what you're talking about, specifically.
Some patchers may think they have completed their work.
Not a name-and-shame, just fair warning their work is considered
incomplete and is about to be rejected as
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
compiled-in parameters that are recorded in pg_control and checked for
compatibility at startup (like BLCKSZ) --- this will prevent anyone from
Simon Riggs wrote:
On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote:
they
It would be good to know who/what you're talking about, specifically.
Some patchers may think they have completed their work.
Not a name-and-shame, just fair warning their work is considered
incomplete
Bruce Momjian wrote:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
It's probably a good idea to have a queue of those too, to allow others
to finish them if the original author hasn't/can't/won't. I'm not sure
which ones you mean.
Joshua D. Drake wrote:
My assumption is if authors don't finish them in the next few days, they
are unlikely to finish them during some grace period during feature
freeze. And the extra time is usually allowed for changes requested by
committers, while at this point the authors aren't
Perhaps it makes sense to say:
Feature Freeze: April 1st., no new patches accepted for 8.3
Patch Freeze April 15th., Authors have until the 15th to address any
committer concerns
Well, I am OK with that, but we need _community_ agreement on that.
I realize it isn't fair that committers
On Wed, 2007-03-28 at 17:12 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote:
they
It would be good to know who/what you're talking about, specifically.
Some patchers may think they have completed their work.
Not a
On Wed, 28 Mar 2007, Simon Riggs wrote:
On Wed, 2007-03-28 at 17:12 -0400, Bruce Momjian wrote:
If everybody knows where everybody stands then we'll all be better off.
There may be other dependencies that need resolution, or last minute
decisions required to allow authors to finish.
Wasn't
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Greg
Sabino Mullane
Sent: woensdag 28 maart 2007 2:50
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Guarenteeing complex referencial
integrity through custom triggers
[snip]
Much too elaborate
On Wed, 2007-03-28 at 17:37 -0400, Bruce Momjian wrote:
I realize it isn't fair that committers are behind on patches, while we
are expecting submitters to make the deadline, but there are far fewer
committers than submitters, and there was never a promise to commit
everything before feature
Running the JDBC driver's regression test suite for the first time in a
while I got a lot of failures that I would have to guess are related to
plan invalidation work. Attached is a self contained test case and the
JDBC driver's log of what protocol messages it is sending.
The end result
Bruce Momjian [EMAIL PROTECTED] writes:
It favours people who are short-sighted and don't see what possible
improvements their code has. No code in an ongoing project like this is ever
completed anyways.
It favors those who do not wait until the last minute, but complete them
well before
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
That's silly, of course people are still working on them, many of these tasks
are open ended and can be improved as long as we have time. just because
they're still working on them doesn't necessarily mean what they have so far
isn't
Gregory Stark wrote:
In any case I think Simon and you have fallen into the trap of thinking of
development as a single-person project. Most developers here, especially
first-time contributors, don't just work in the dark on their own and turn up
with a finished patch. They have questions and
On 3/29/07, Florian G. Pflug [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
Tom, please correct me if I am wrong. But ISTM that this idea might
work in this context. In get_relation_info(), we would check if
xcreate
xid stored in pg_index for the index under consideration is seen
committed
Simon Riggs [EMAIL PROTECTED] writes:
My feeling is we should have more regular sync points where the patch
queue is emptied and everything committed or rejected.
No doubt, but the real problem here is that reviewing/committing other
people's patches is not fun, it's just work :-(. So it's no
74 matches
Mail list logo
