On Wed, 2007-02-28 at 21:09 -0500, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
Simon Riggs wrote:
It's been pointed out to me that I introduced a bug as part of the
recent optimisation of COPY-after-truncate.
The attached patch fixes
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Simon Riggs wrote:
On Wed, 2007-02-28 at 21:09 -0500, Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
Simon Riggs wrote:
It's been pointed out to me that I introduced a bug as part of the
recent optimisation of COPY-after-truncate.
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I have coded up the following patch which places LOG just above ERROR in
log_min_error_statement.
LOG_NO_STATEMENT? What *are* you thinking? The kindest word I can find
for this is baroque.
What I had in mind was a one-line
what is the point of this?:
+ void
+ RelationCacheResetAtEOXact(void)
+ {
+ need_eoxact_work = true;
+ }
and why is it declared extern in relcache.h when it is only used in
relcache.c?
ISTM that there isn't much reason to un-inline the statement, and the
patch could be a lot
I'm sorry. I misread the patch. I now see it used in index.c. return to
normal viewing ...
cheers
andrew
Andrew Dunstan wrote:
what is the point of this?:
+ void
+ RelationCacheResetAtEOXact(void)
+ {
+ need_eoxact_work = true;
+ }
and why is it declared extern in relcache.h
On Thu, 2007-03-01 at 09:12 -0500, Andrew Dunstan wrote:
what is the point of this?:
+ void
+ RelationCacheResetAtEOXact(void)
+ {
+ need_eoxact_work = true;
+ }
and why is it declared extern in relcache.h when it is only used in
relcache.c?
It is called from index.c and
Simon Riggs wrote:
On Thu, 2007-03-01 at 09:12 -0500, Andrew Dunstan wrote:
what is the point of this?:
+ void
+ RelationCacheResetAtEOXact(void)
+ {
+ need_eoxact_work = true;
+ }
and why is it declared extern in relcache.h when it is only used in
relcache.c?
It is called
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
We are happy to provide that. If and when it comes to the final patch being
accepted, we can send a copyright waiver mail which will put our source code
contribution under the BSD license.
This approach is not practically workable
Pavel Stehule wrote:
this patch ensures independency datetime fields on current datestyle
setting. Add new internal datestyle USE_XSD_DATESTYLE. It's almoust
same to USE_ISO_DATESTYLE.
I've installed this patch and made some additional adjustments so the
time zone format matches the XSD
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
You understand that this fixes a bug in CVS HEAD?
This is for CVS HEAD only, right? Fixed still go into the queue, but
for a shorter amount of time, hopefully.
It still needs review ... and the presence of the patch in the queue
One complaint we've heard from clients trying out EDB or PostgreSQL is
that loading data is slower than on other DBMSs.
I ran oprofile on a COPY FROM to get an overview of where the CPU time
is spent. To my amazement, the function at the top of the list was
PageAddItem with 16% of samples.
Heikki Linnakangas wrote:
Attached is a fix for that. It adds a flag to each heap page that
indicates that there isn't any free line pointers on this page, so
don't bother trying. Heap pages haven't had any heap-specific
per-page data before, so this patch adds a HeapPageOpaqueData-struct
Heikki Linnakangas wrote:
One complaint we've heard from clients trying out EDB or PostgreSQL is
that loading data is slower than on other DBMSs.
I ran oprofile on a COPY FROM to get an overview of where the CPU time
is spent. To my amazement, the function at the top of the list was
Heikki Linnakangas [EMAIL PROTECTED] writes:
On every row, PageAddItem will scan all the line pointers on the target
page, just to see that they're all in use, and create a new line
pointer. That adds up, especially with narrow tuples like what I used in
the test.
Attached is a fix for
Bruce Momjian [EMAIL PROTECTED] writes:
What are *you* thinking? Yes, that patch has that line, but
log_statement and log_min_duration_statement is going to trigger
log_min_error_statement so you are going to get the statement printed
twice.
What's wrong with that? If a statement triggers
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On every row, PageAddItem will scan all the line pointers on the target
page, just to see that they're all in use, and create a new line
pointer. That adds up, especially with narrow tuples like what I used in
the test.
Attached is
Heikki Linnakangas [EMAIL PROTECTED] writes:
At the end of the thread, Bruce added the patch to his hold-queue, but I
couldn't find a trace of it after that so I'm not clear why it was
rejected in the end. This comment (by you) seems most relevant:
I believe we concluded that the distributed
Tom Lane wrote:
As you say, pd_tli is not really pulling its weight, but I'm also loath
to remove it, as in a multi-timeline situation the page LSN is really
not well defined if you don't know which timeline it refers to.
Now we'd only need 16 bits to store the last-used offset, or a flags
Heikki Linnakangas wrote:
Tom Lane wrote:
I'm not sure whether I like your flag approach better than the
last-used-offset one. The previous patch probably buys some teeny
amount more performance, but the flag seems more robust (noting in
passing that neither patch attempts to WAL-log its
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'll post a patch along those lines.
Here it is.
I'm not fond of the macro names for the flag, but couldn't think of
anything shorter yet descriptive.
Let's reverse the sense of the flag bit; this seems a good idea since
the initial state should
On Fri, 2 Mar 2007 01:20, Simon Riggs wrote:
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
Hi Simon,
We are happy to provide that. If and when it comes to the final patch
being accepted, we can send a copyright waiver mail which will put our
source code contribution under the
I wrote:
Barring objections, I'll tweak this as above and apply.
I've applied the attached modified version of this patch. It seemed
better to me to centralize the handling of this flag bit in PageAddItem
and PageRepairFragmentation, instead of having it in the callers as you
did. This means
Resending once again, all my previous attempts seems to have failed.
Is there a limit on patch size on -patches as well ? Attached is
a gzipped version.
Hi All,
Please see the version 4.0 of HOT WIP patch attached with the mail.
ISTM that this version has one of the most radical changes
Gregory Stark [EMAIL PROTECTED] writes:
If we stored the digits in base 2 with a base 10 exponent would it really be
too hard to output the digits?
Exact decimal fractions are no longer exact when converted to base 2.
regards, tom lane
---(end
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane schrieb am 02.03.2007 14:38:
Gregory Stark [EMAIL PROTECTED] writes:
If we stored the digits in base 2 with a base 10 exponent would it really be
too hard to output the digits?
Exact decimal fractions are no longer exact when converted
Patric Bechtel [EMAIL PROTECTED] writes:
Tom Lane schrieb am 02.03.2007 14:38:
Exact decimal fractions are no longer exact when converted to base 2.
I think multiplying with base 10 until it's a whole number, then saving
that exponent with it, that's how I understood it.
That hardly seems
Hi Gavin,
Thanks for your comments.
I shall set up the ctids list to be stored in memory initially and dump to a
temp file if needed.
Regards,
John Bartlett
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gavin Sherry
Sent: Wednesday, 28 February 2007
28 matches
Mail list logo
