ITAGAKI Takahiro wrote:
Andrew Dunstan [EMAIL PROTECTED] wrote:
OK, here is a patch that I think incorporates all the ideas discussed
(including part of Mark Mielke's suggestion about optimising %_). There
is now no special treatment of UTF8 other than its use of a faster
NextChar
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
if (pset.c-db-asyncStatus != PGASYNC_BUSY)
{
break;
}
There already is a defined API for
Gavin Sherry wrote:
Hi all,
Attached is an updated bitmap index patch. It contains bug fixes, API
changes, binary changes (page identifier to distinguish it from other
indexes) and has been brought up to HEAD.
I worked on a few approaches to VACUUM, none very satisfactory. The
problem is,
Andrew Dunstan [EMAIL PROTECTED] writes:
Unless you have a better solution I think we'd better do that, though.
I notice that the header is also included in command.c even though it doesn't
use PGASYNC_IDLE.
Are you going to make these fixes?
Yes, sorry, I started to already but got
Greg Smith wrote:
The attached patch fixes all the issues I found in the original
version of this code and completes the review I wanted to do. Someone
else will need to take this from here. As I already mentioned, I
can't comment on the quality of the piping implementation used to add
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Pavan Deolasee wrote:
On 1/28/07, Tom Lane [EMAIL PROTECTED] wrote:
OTOH it might be
cleaner to refactor
Mike Rylander wrote:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable
(or, in fact, unwilling) to upgrade to 8.3 for quite some time.
Because this patch is completely backward compatible it can
(theoretically)
Peter Eisentraut wrote:
Mike Rylander wrote:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable
(or, in fact, unwilling) to upgrade to 8.3 for quite some time.
?Because this patch is completely backward
On 6/1/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
Mike Rylander wrote:
I understand that XML support is planned and at least partially
implemented for 8.3, but many production instances will be unable
(or, in fact, unwilling) to upgrade to 8.3 for quite some time.
Because this patch is
XML is now more stabilized in the backend than when the patch appeared,
and it doesn't make sense to add features to a /contrib interface that
is to be used only for backward compatability.
Patch rejected. You can put the patch on pgfoundry if you are worried
others might need this
Bruce Momjian [EMAIL PROTECTED] writes:
This has been saved for the 8.4 release:
I think it should be dropped entirely. The argument against was that
it complicated the code in a non-performance-critical path, and that
argument isn't going to be different next time.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it should be dropped entirely. The argument against was that
it complicated the code in a non-performance-critical path, and that
argument isn't going to be different next time.
I only kept it for 8.4 because I was worried it
Patch rejected, not held for 8.4, because it uglifies the code.
---
Pavan Deolasee wrote:
On 1/28/07, Tom Lane [EMAIL PROTECTED] wrote:
OTOH it might be
cleaner to refactor things that way, if we were going to apply
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it should be dropped entirely. The argument against was that
it complicated the code in a non-performance-critical path, and that
argument isn't going to be different next time.
I only kept it for 8.4
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, here is a patch that I think incorporates all the ideas discussed
(including part of Mark Mielke's suggestion about optimising %_). There
is now no special treatment of UTF8 other than its use of a faster
NextChar macro.
Looks mostly pretty
Andrew Dunstan [EMAIL PROTECTED] writes:
ITAGAKI Takahiro wrote:
| SQL_ASCII | LATIN1 | UTF8 | EUC_JP
-+---++---+-
HEAD| 8017 | 8029 | 16928 | 18213
Patched | 7899 | 7887 | 9985 | 10370 [ms]
It improved the performance not
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, here is a patch that I think incorporates all the ideas discussed
(including part of Mark Mielke's suggestion about optimising %_). There
is now no special treatment of UTF8 other than its use of a faster
NextChar macro.
Andrew Dunstan wrote:
I'd suggest adding something like If we are in the middle of a
multibyte character, we must already have matched at least one byte of
the character from both text and pattern; so we cannot get out-of-sync
on character boundaries. And we know that no backend-legal
On 6/2/07, Bruce Momjian [EMAIL PROTECTED] wrote:
OK, removed from 8.4 queue.
I am OK with this, though I personally never felt that it complicated
the code :-)
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
On Fri, 1 Jun 2007, Andrew Dunstan wrote:
Greg Smith wrote:
Since the rotation size feature causes other issues anyway
that make importing more complicated, documenting the issue seemed
sufficient.
What are the other issues? I'm not happy about producing files with split
lines.
Just that
20 matches
Mail list logo
