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 into 8.3 (and so we shouldn't
Hello Tom,
All what you wrote is true. plpgpsm copies-and-pastes about 30% of code and
It is terrible for long run. But when I can change it? Writing differnt
runtime is nonsense, better way is refactoring plpgsql and then sharing code
with its. It's not propable in 8.4 .. there will by lot o
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
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
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
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
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
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
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 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
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 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
* [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
"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
"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
>
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
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
"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
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
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
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
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/
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
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
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
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
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
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
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:
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
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
31 matches
Mail list logo
