From: "Greg Smith" <[EMAIL PROTECTED]>
> If you compare how Oracle handles their writes and checkpoints to
the
> Postgres code, it's obvious they have a different architecture that
> enables them to support sync writing usefully. I'd recommend the
Database
> Writer Process section of
>
http://www.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I wrote:
>> stark <[EMAIL PROTECTED]> writes:
>>> [ packed varlena patch ]
>
>> Applied with revisions.
>
> Forgot to mention: one of the revisions was to not add the "sizes.sql"
> test, because the output was platform-dependent and is likely to get
> more
On Fri, 2007-04-06 at 02:53 -0400, Greg Smith wrote:
> If you compare how Oracle handles their writes and checkpoints to the
> Postgres code, it's obvious they have a different architecture that
> enables them to support sync writing usefully. I'd recommend the
> Database
> Writer Process secti
Current version of postgres support only 1GB chunks. This limit is
defined in the pg_config_manual.h header file. However this setting
allows to have maximal 2GB chunks. Main problem is that md storage
manager and buffile use "long" data type (32bits) for offset instead
"off_t" defined in .
o
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> The attached is a patch to optimize contrib/pgbench using new 8.3 features.
>
> - Use DROP IF EXISTS to suppress errors for initial loadings.
> - Use a combination of TRUNCATE and COPY to reduce WAL on creating
> the accounts table.
Zdenek Kotala wrote:
Current version of postgres support only 1GB chunks. This limit is
defined in the pg_config_manual.h header file. However this setting
allows to have maximal 2GB chunks. Main problem is that md storage
manager and buffile use "long" data type (32bits) for offset instead
Andrew Dunstan wrote:
Does it mean the maximum field size will grow beyond 1Gb?
No. Because it is limited by varlena size. See
http://www.postgresql.org/docs/8.2/interactive/storage-toast.html
Or give better performance?
Yes. List of chunks is stored as linked list and for some operati
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Forgot to mention: one of the revisions was to not add the "sizes.sql"
>> test, because the output was platform-dependent and is likely to get
>> more so if any ability to change the toast thresholds gets put in.
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Or give better performance?
> Yes. List of chunks is stored as linked list and for some operation
> (e.g. expand) are all chunks opened and their size is checked. On big
> tables it takes some time. For example if you have 1TB
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Indeed, but that would be far more effectively addressed by fixing the
*other* code path that doesn't segment at all (the
LET_OS_MANAGE_FILESIZE option, which is most likely broken these days
for lack of testing).
On Fri, 6 Apr 2007, Takayuki Tsunakawa wrote:
Hmm... what makes you think that sync writes is useful for Oracle and
not for PostgreSQL?
They do more to push checkpoint-time work in advance, batch writes up more
efficiently, and never let clients do the writing. All of which make for
a diffe
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> http://www.sigaev.ru/misc/indexnulls-0.8.gz
Applied with revisions (except I didn't touch the gist code, figuring
you probably understand that better than me).
regards, tom lane
---(end of broadcast)-
Folks,
Per a question Alexey Parshin asked in the IRC channel, I'm attaching
a patch to the GRANT and REVOKE syntax summaries which replaces the
misleading word "column" with "parameter." "Column" is misleading
because it could be read to imply a column-level GRANT/REVOKE, which
we don't have yet
David Fetter <[EMAIL PROTECTED]> writes:
> Per a question Alexey Parshin asked in the IRC channel, I'm attaching
> a patch to the GRANT and REVOKE syntax summaries which replaces the
> misleading word "column" with "parameter." "Column" is misleading
> because it could be read to imply a column-le
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
Per a question Alexey Parshin asked in the IRC channel, I'm attaching
a patch to the GRANT and REVOKE syntax summaries which replaces the
misleading word "column" with "parameter." "Column" is misleading
because it could be read to imp
"Gurjeet Singh" <[EMAIL PROTECTED]> writes:
> Please find attached the latest version of the patch. It applies cleanly on
> REL8_2_STABLE.
The interface to the planner in this seems rather brute-force. To run
a plan involving a hypothetical index, you have to make a bunch of
catalog entries, run
Russell Smith <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The entire *point* of that paragraph is that we don't have the
>> feature. This proposed change is surely not an improvement...
>>
> Maybe removing the entire example would be more helpful. I don't find
> it clear to have a command
FYI, patch applied by Tatsuo. Thanks.
---
ITAGAKI Takahiro wrote:
> The attached is a patch to optimize contrib/pgbench using new 8.3 features.
>
> - Use DROP IF EXISTS to suppress errors for initial loadings.
> - Use a co
FYI, patch applied by Tatsuo. Thanks.
---
Greg Smith wrote:
> This patch changes the way pgbench outputs its latency log files so that
> every transaction gets a timestamp and notes which transaction type was
> executed.
Correct the spelling of SYMMETRIC.
--
Michael Fuhr
Index: doc/src/sgml/func.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/func.sgml,v
retrieving revision 1.375
diff -c -r1.375 func.sgml
*** doc/src/sgml/func.sgml 5 Apr 2007
Patch applied. Thanks. Your documentation changes can be viewed in
five minutes using links on the developer's page,
http://www.postgresql.org/developer/testing.
---
Michael Fuhr wrote:
> Correct the spelling of SYMMETRI
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.
---
Pa
Tom Lane wrote:
> Russell Smith <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The entire *point* of that paragraph is that we don't have the
> >> feature. This proposed change is surely not an improvement...
> >>
> > Maybe removing the entire example would be more helpful. I don't find
>
I do not understand this patch. You have defined two functions,
UTF8MatchText() and UTF8MatchTextIC(), and the difference between them
is that one calls CHAREQ and the other calls ICHAREQ, but just above
those two functions you define the macros identically:
#define CHAREQ(p1, p2)wch
Please remove \cwait and supply an updated version with documentation.
---
stark wrote:
>
> This is just an update against CVS.
>
> The interface is still as described at this URL:
>
> http://community.enterprisedb.com/co
Bruce Momjian wrote:
>
> I do not understand this patch. You have defined two functions,
> UTF8MatchText() and UTF8MatchTextIC(), and the difference between them
> is that one calls CHAREQ and the other calls ICHAREQ, but just above
> those two functions you define the macros identically:
>
>
26 matches
Mail list logo
