Tatsuo Ishii [EMAIL PROTECTED] writes:
The patches look good to me.
Please commit whatever you think is reasonable.
BTW, is anybody working on enabling the fill factor to the tables used
by pgbench? 8.3 will introduce HOT, and I think adding the feature
will make it easier to test HOT.
I'm
On Fri, 6 Apr 2007, Takayuki Tsunakawa wrote:
could anyone evaluate O_SYNC approach again that commercial databases
use and tell me if and why PostgreSQL's fsync() approach is better than
theirs?
I noticed a big improvement switching the WAL to use O_SYNC (+O_DIRECT)
instead of fsync on my
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
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 so if any ability to
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 section
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
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
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.
Can we
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 big
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
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
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.
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 imply a
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 the
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 outline in
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
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
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
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.
---
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
it clear to
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)
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:
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:
27 matches
Mail list logo
