David Fetter [EMAIL PROTECTED] writes:
On Mon, Apr 09, 2007 at 06:43:08PM -0400, Tom Lane wrote:
So this does not really add any new functionality, it's just variant
syntax for something you can do about as easily without it, right?
Not totally as easily. For example, you can do some kinds
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO:
o Allow single-byte header storage for arrays
Fwiw this is single-byte header storage for varlena array *elements*
The arrays themselves already get the packed varlena treatment.
--
Gregory Stark
EnterpriseDB
Hi,
On 4/10/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Added to TODO:
o Have WITH CONSTRAINTS also create constraint indexes
http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
Trevor's patch does add unique/primary indexes. This would mean that we have
to remove
Simon Riggs [EMAIL PROTECTED] wrote:
transaction_guarantee.v11.patch
correct files attached
This is a small fix to transaction_guarantee patch.
WAL writer needs PGSharedMemoryReAttach() on EXEC_BACKEND platforms.
Other changes are only for suppressing warnings.
We might also need to
Here is new version that adds following changes:
4. Function is now strict, per discussion.
5. Return empty array in case when XPath expression detects nothing
(previously, NULL was returned in such case), per discussion.
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml
Nikolay Samokhvalov wrote:
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml version=1.0?a /b /'); // now XML datum is always wrapped
with dummy x.../x, XML prologue simply goes away (if any).
Is that legal XML? I though only documents could have prologs.
cheers
Am Dienstag, 10. April 2007 15:17 schrieb Andrew Dunstan:
Nikolay Samokhvalov wrote:
6. (bugfix) Work with fragments with prologue: select xpath('/a',
'?xml version=1.0?a /b /'); // now XML datum is always wrapped
with dummy x.../x, XML prologue simply goes away (if any).
Is that legal
Koichi Suzuki [EMAIL PROTECTED] writes:
My proposal is to remove unnecessary full page writes (they are needed
in crash recovery from inconsistent or partial writes) when we copy WAL
to archive log and rebuilt them as a dummy when we restore from archive
log.
...
Benchmark: DBT-2
I wrote:
This patch looks fairly sane to me; I have a few small gripes about
coding style but that can be fixed while applying. Heikki, you were
concerned about the cycle-ID idea; do you have any objection to this
patch?
Actually, on second look I think the key idea here is Takahiro-san's
Hi Tom,
The original patch was submitted by Kai Sattler, and we (at EDB) spent a
lot of time improving it, making it as seamless and as user-friendly as
possible. As is evident from the version number of the patch (v26), it has
gone through a lot of iterations, and was available to the
Alvaro Herrera wrote:
Ok, here it is, after considerable rejiggering.
Hum, just noticed a leftover from a previous version; the changes to
procarray.c, sinvaladt.c and lock.c should be discarded (they are just
about adding autovacuum_max_workers to code that uses MaxBackends). The
changes are
I wrote:
Actually, on second look I think the key idea here is Takahiro-san's
introduction of a cancellation flag in the hashtable entries, to
replace the cases where AbsorbFsyncRequests can try to delete entries.
What that means is mdsync() doesn't need an outer retry loop at all:
I fooled
Pavel Stehule [EMAIL PROTECTED] writes:
this patch allows using SQL2003 syntax for set returning functions. It is
based on using new type of argmode - PROARGMODE_TABLE.
I've been looking at this, and my feeling is that we should drop the
PROARGMODE_TABLE business and just define RETURNS
I wrote:
I fooled around with this idea and came up with the attached patch.
It seems to do what's intended but could do with more eyeballs and
testing before committing. Comments please?
Earlier I said that I didn't want to back-patch this change, but on
looking at the CVS history I'm
Hi,
In the case below, we run DBT-2 benchmark for one hour to get the
measure. Checkpoint occured three times (checkpoint interval was 20min).
For more information, when checkpoint interval is one hour, the amount
of the archived log size was as follows:
cp: 3.1GB
gzip:
In terms of idle time for gzip and other command to archive WAL offline,
no difference in the environment was given other than the command to
archive. My guess is because the user time is very large in gzip, it
has more chance for scheduler to give resource to other processes. In
the
Ühel kenal päeval, T, 2007-04-10 kell 18:17, kirjutas Joshua D. Drake:
In terms of idle time for gzip and other command to archive WAL offline,
no difference in the environment was given other than the command to
archive. My guess is because the user time is very large in gzip, it
has
17 matches
Mail list logo
