Simon Riggs wrote:
> On Wed, 2007-09-12 at 17:47 -0400, Bruce Momjian wrote:
> > For those who have forgotten the progress we have made toward 8.3, here
> > are the open patches we had for 8.3 as of May 1, 2006:
>
> Could you please issue a list of open items for 8.3?
>
> I want to check whether
Pavan Deolasee wrote:
> On 9/13/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> >
> > For those who have forgotten the progress we have made toward 8.3, here
> > are the open patches we had for 8.3 as of May 1, 2006:
> >
> >
> You mean May 1, 2007 ;-)
Yea, sorry.
--
Bruce Momjian <[EMAIL P
On Wed, 2007-09-12 at 17:47 -0400, Bruce Momjian wrote:
> For those who have forgotten the progress we have made toward 8.3, here
> are the open patches we had for 8.3 as of May 1, 2006:
Could you please issue a list of open items for 8.3?
I want to check whether you are waiting on me for anythin
On 9/13/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>
> For those who have forgotten the progress we have made toward 8.3, here
> are the open patches we had for 8.3 as of May 1, 2006:
>
>
You mean May 1, 2007 ;-)
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
For those who have forgotten the progress we have made toward 8.3, here
are the open patches we had for 8.3 as of May 1, 2006:
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > FYI, Tom, Heikki, I need one
Heikki Linnakangas wrote:
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Did we ever get a broken up patch for this?
Yes:
http://archives.postgresql.org/pgsq
Joshua D. Drake wrote:
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all the
On 5/17/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
>
>
> There are few things that we can separate easily, like CREATE INDEX
> related changes, VACUUM and VACUUM FULL related changed, space
> reuse related changes etc. Let me give it a shot.
Did we ever get a broken u
Joshua D. Drake wrote:
> Tom Lane wrote:
>
> > At this point it seems nothing will be done about this issue for 8.3.
> >
> > * [PATCHES] plpgpsm /Pavel Stehule/
> >
> > I think this has to be held for 8.4: it was submitted too late for the 8.3
> > feature deadline, and in fact I don't recall th
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all the
code to handle sca
Tom Lane wrote:
At this point it seems nothing will be done about this issue for 8.3.
* [PATCHES] plpgpsm /Pavel Stehule/
I think this has to be held for 8.4: it was submitted too late for the 8.3
feature deadline, and in fact I don't recall that there was any community
discussion/consensus o
Sorry for late responce due to very long vacation season in Japan.
Tom Lane wrote:
> > * Re: [PATCHES] [HACKERS] Full page writes improvement, code update
> >/Koichi Suzuki/
> >
> > I feel that we have to insist that this be modified to not create
any WAL
> > bloat in the pre-compression
On 5/2/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
Can we? I mean, sure you can break the patch up into chunks which might
make
it easier to read, but are any of the chunks useful alone?
Well I agree, it would be a tough job. I can try and break the patch into
several self-complete incremen
On Tue, 2007-05-01 at 22:44 -0400, Tom Lane wrote:
Nice summary Tom.
> * Re: [PATCHES] [Fwd: Deferred Transactions, Transaction Guarantee
> and COMMITwithout waiting] /Simon Riggs/
>
> Simon is on the hook to submit an updated patch. I hope this one
> makes it in, as it looks like a real
http://www.sigaev.ru/misc/tsearch_core-0.46.gz
Patch is synced with current CVS HEAD and synced with bugfixes in
contrib/tsearch2
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
Tom Lane wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break things, I'm not in favor of reduci
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of getting int
Another complexity is testing cases where the table fits in shared
memory/RAM, and those that don't, and testing cases where heap fits in
RAM only because we pushed things to TOAST, and cases where we have to
do lots of TOAST access that doesn't fit in RAM. I wonder if it is even
worth testing it
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Then, figure out where the gains on the non-TEXT field seem to diminish
> in usefulness. Basically, with a lower TOAST value, we are going to
> spend more time accessing the TEXT field, but the speedup for the
> non-TEXT field should be large enough
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> FYI, Tom, Heikki, I need one of you to post the list of patches and
> >> where we think we are on each one, even if the list is imperfect.
> >
> > This message is an attempt to sort o
On Tue, May 01, 2007 at 10:44:38PM -0400, Tom Lane wrote:
> * [PATCHES] Preliminary GSSAPI Patches /Henry B. Hotz/
>
> Magnus is reviewing this one.
Check.
> * [PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows
>/ITAGAKI Takahiro/
>
> Someone else needs to look at this; I ca
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> FYI, Tom, Heikki, I need one of you to post the list of patches and
>> where we think we are on each one, even if the list is imperfect.
>
> This message is an attempt to sort out which patch queue entries have
>
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 5/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>>
>> This needs a *lot* of review. Can we break it down into more manageable
>> chunks?
>
> Sure, we can do that. I actually did that when I posted the
> incremental versions of the HOT-patch, each ve
* [PATCHES] Updateable cursors patch /FAST PostgreSQL/
This is incomplete, and I fear at this point has to be held over to 8.4.
It is true that my original patch post said that I need to modify the
patch to work with tidscan. Since then I have realized that this
modification is not needed a
On Tue, 1 May 2007, Tom Lane wrote:
* [HACKERS] tsearch_core patch for inclusion
/Teodor Sigaev/
Have we resolved whether the API and the dump/restore strategy are
acceptable? The code needs review too, but not till we've settled
on the basic question whether we like the feature set.
Th
On 5/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
* [PATCHES] HOT Patch - Ready for review /Pavan Deolasee/
This needs a *lot* of review. Can we break it down into more manageable
chunks? I'm not sure that anyone's got a full grasp of the implications
of this patch, and that's a scary thought
On 5/2/07, Tom Lane <[EMAIL PROTECTED]> wrote:
* [pgsql-patches] Ctid chain following enhancement
/Pavan Deolasee/
I'm not very excited about this --- it seems to me to complicate the code
in some places that are not in fact performance-critical. While it
doesn't seem likely to break
Greg Smith <[EMAIL PROTECTED]> writes:
> On Tue, 1 May 2007, Tom Lane wrote:
>> * Re: [PATCHES] Synchronized Scan WIP patch
>> /Simon Riggs/
>> Heikki is reviewing this one. Also I believe Greg Smith is doing more
>> performance testing.
> Actually it was the "Automatic adjustment of bgwriter_lru
On Tue, 1 May 2007, Tom Lane wrote:
* Re: [PATCHES] Synchronized Scan WIP patch
/Simon Riggs/
Heikki is reviewing this one. Also I believe Greg Smith is doing more
performance testing.
Actually it was the "Automatic adjustment of bgwriter_lru_maxpages" patch
from Itagaki Takahiro I've b
29 matches
Mail list logo
