"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'
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
> co
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 ne
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'
"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
>
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 is
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 featu
>-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
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.
Was
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.
>
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
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 are
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.
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
> in
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
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
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.
>
> Ye
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 poin
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.
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
"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 fre
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
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
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
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 beca
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
> > t
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.
>
> T
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
si
"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
cre
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?
Wh
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
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 actu
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 cat
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 > xcr
"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
operation
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 ha
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
"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
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 f
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 a
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
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 pro
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
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 inde
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
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 arra
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 DefineRela
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
"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 co
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 n
> > 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 wo
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)---
T
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
"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 wi
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
> >
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
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".
> Thi
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 "a
"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".
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
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
command
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:
> CREA
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 to
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 "use
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?
When
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 gener
"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 patc
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
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 oz
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_du
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_b
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%
72 matches
Mail list logo
