Some AMD64 dual core processor series has problem with atomic operation
lock cmpxchg. It does not work correctly in some case. (I don't know
if it is bug or feature.) This problem occurred in the solaris on the
AMD64 platform. Postgres implement own lock mechanism with similar code
lock xchg. I
I would like to implement following item from TODO list:
* Allow commenting of variables in postgresql.conf to restore them to
defaults. Currently, if a variable is commented out, it keeps the
previous uncommented value until a server restarted.
Does anybody work on it?
I performed some
Alvaro Herrera wrote:
Zdenek Kotala wrote:
I performed some investigation and I found that signal handler
(SIGHUP_handler) contents a big code and contents signal nonsafe
functions. It should generate deadlock or damage some internal data
structure in the standard c library. See
I'm interesting in problem "Allow commenting of variables in
postgresql.conf to restore them to defaults". And I need some clarify
of SET command behavior.
Res_value is defined in the source code as highest overriding setting
during startup (or reconfiguration) and it is used for store
I would like to implement Allow postgresql.conf file values to be
changed via an SQL API, perhaps using SET GLOBAL functionality. Is
there anybody who works on it? Is there any detailed explanation?
Thanks Zdenek
---(end of broadcast)---
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX). Pgbench with 64bit
transaction ID has to pay about a couple of percent of performance.
If 64bit transaction ID is a reasonable fix, I've already posted
Mark,
I don't know how it will exactly works in postgres but my expectations are:
Mark Woodward wrote:
Is there a difference in PostgreSQL performance between these two
different strategies:
if(!exec(update foo set bar='blahblah' where name = 'xx'))
exec(insert into foo(name, bar)
I would like to implement Mark change-on-restart-only values in
postgresql.conf item. Anybody works on this? Does it mean add extra
comment to postgresql.conf for variable which has PG_POSTMASTER context?
Zdenek
---(end of broadcast)---
Josh Berkus wrote:
Zdenek,
I would like to implement Mark change-on-restart-only values in
postgresql.conf item. Anybody works on this? Does it mean add extra
comment to postgresql.conf for variable which has PG_POSTMASTER context?
Somehow I thought you'd already submitted a patch?
I sent
Peter Eisentraut wrote:
One frequent source of confusion are the different units that the parameters
in postgresql.conf use. shared_buffers is in 8 kB, work_mem is in 1 kB;
bgwriter_delay is in milliseconds, checkpoint_warning is in seconds.
Obviously, we can't change that without
Peter Eisentraut wrote:
Zdenek Kotala wrote:
Time units is easy:
1h = 60min = 3600s = 360ms
We don't need anything larger than seconds at the moment.
What kind of unit prefix will we use for memory?
PostgreSQL has always used 1 kB = 1024 B.
1) will be unit required?
No.
What
moises wrote:
Can any body talk me how many transactions make postgres in a second?
It depends on many things
1) speed of hardware/OS/number of disks/type of disks, if you use RAID
or not ...
2) number concurrent access
3) size of processed data in one transaction
4) database model
...
It
Andrew Dunstan wrote:
Tom Lane wrote:
I see one occurrence in the 8.1 branch on hyena, but the failure
probability seems to have jumped way up in HEAD since we put in the
C-coded pg_regress. This lends weight to the idea that it's a
timing-related issue, because pg_regress.c is presumably
Josh Berkus napsal(a):
Zdenek,
However what happened? I think that following scenarios occurred.
Postmaster listen only in one process and there are many clients run
really parallel. T2000 server has 32 threads ( 8 core and each has 4
threads). These clients generate more TCP/IP request at one
Josh Berkus wrote:
Zdenek,
However what happened? I think that following scenarios occurred.
Postmaster listen only in one process and there are many clients run
really parallel. T2000 server has 32 threads ( 8 core and each has 4
threads). These clients generate more TCP/IP request at one
Neil Conway napsal(a):
However, is there a reason to use Trac beyond the fact that it is
already setup? ISTM we only need a wiki, and don't need the other
features of Trac, such as the bug tracker.
I do not agree. How you determine what release fixes the bug now? We
have web page and mailing
Bruce, Andrew, Tom.
I little bit confuse now, what status of this patch is? I check your
observation and I agree with them. But I don't where is ball now and
what I can/must do now like author of this patch?
Thanks for explanation
Zdenek
Bruce Momjian napsal(a):
OK,
Andrew Dunstan napsal(a):
Even at 32 this hardly seems to be a likely cause of the problem. I
think the maximum parallelism of our tests is around 20. Anyway, lets's
get the patch installed - I have a test regime set up that will
reproduce the error moderately reliably within about a dozen
Is everything ok with postgres mail server? I have problem to send mail
to hackers list and pgadmin-hacker as well. If somebody is on cc, he
receives mail correctly, but it does not appear in the list. Any suggestion?
Zdenek
---(end of
Is everything ok with postgres mail server? I have problem to send mail
to hackers list and pgadmin-hacker as well. If somebody is on cc, he
receives mail correctly, but it does not appear in the list. Any
suggestion? This problem first occurred when I sign into pgadmin-hacker
list.
Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Zdenek Kotala
Sent: 23 August 2006 08:07
To: Josh Berkus; Bruce Momjian; pgsql-hackers@postgresql.org;
[EMAIL PROTECTED]
Subject: [HACKERS] Problem with mailing list?
Is everything
I'm working on pg_upgrade concept. I try to determine what is changed
from 8.1 to 8.2. There is list of important areas for upgrade and
suggested action.
1) BKI - catalog.
There are a lot of changes. See attached file.
a) There is new table pg_shdescription
action: create
b)
Martijn van Oosterhout wrote:
On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote:
snip
1) BKI - catalog.
c) Some records are changed
action: ???
They just need to be changed. In principle the datalog needs to be
updated so it looks like a database initdb'd with the new
Jim C. Nasby wrote:
On Wed, Aug 23, 2006 at 10:49:05AM +0200, Martijn van Oosterhout wrote:
8) WAL/XLOG
Question: Should be deleted?
I imagine you should probably force a checkpoint and then wipe the wal
records. The WAL isn't going to be able to cover some of the stuff done
during the
Zdenek Kotala napsal(a):
Martijn van Oosterhout wrote:
On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote:
5) Tuples
question: Does have data types some disk representation?
Does have tupleheader same structure?
I think only the inet/cidr types changed format
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why is this a good idea
Alvaro Herrera wrote:
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I little bit enhanced overview catalog tables. I added two new columns.
First one is OID of catalog table and second one contains attributes
which determine if the table is bootstrap, with oid and global.
Why
I discussed with Gavin about pg_downgrade process. I think that it
should be much dangerous and more complex problem than upgrade. Some
operation on the new system should makes downgrade impossible ...
My experience with database upgrades is that downgrade is requested only
if there some show
Gavin Sherry wrote:
On Wed, 20 Sep 2006, Andrew Sullivan wrote:
On Wed, Sep 20, 2006 at 12:54:14PM +0200, Zdenek Kotala wrote:
My first question is how important is downgrade for You and Your customers?
And second is how to verify that downgrade is possible?
Well, one way to do
Simon Riggs napsal(a):
Improved monitoring and performance tuning (Tom, Bruce, Greg, Larry)
Overhead of statistics collection has been considerably reduced and new
statistics and system information is available. Better query logging
improves diagnostics and especially performance
I'm playing with catalog upgrade via BKI format. I enhanced the pg_dump
of BKI output (not patch ready yet). I'm using it for some test now, but
I think It should be useful for some one other, for example some
application with embedded postgres should use own prepared BKI for
database init
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I'm playing with catalog upgrade via BKI format. I enhanced the pg_dump
of BKI output (not patch ready yet). I'm using it for some test now, but
I think It should be useful for some one other, for example some
application with embedded
I tried regression test with Postgres Beta and horology test field. See
attached log. It appears few month ago - see
http://archives.postgresql.org/pgsql-ports/2006-06/msg4.php
I used Sun Studio 11 with -fast flag and SPARC platform.
I played little bit with cc flags and following flags
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
But the question is if the -fast flag is good for postgres. The -fast
flag sets brutal floating point optimization and some operation should
have less precision. Is possible verify that floating point operation
works well?
That's
Bruce Momjian napsal(a):
Zdenek Kotala wrote:
I tried regression test with Postgres Beta and horology test field. See
attached log. It appears few month ago - see
http://archives.postgresql.org/pgsql-ports/2006-06/msg4.php
I used Sun Studio 11 with -fast flag and SPARC platform.
Are you
Josh Berkus napsal(a):
Zdenek,
Hmmm ... we're not using the -fast option for the standard PostgreSQL
packages. Where did you start using it?
Yes, I know. The -fast option generates architecture depending code and
it is not possible use in common packages. I found out this option when
I
Andrew Dunstan napsal(a):
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
But the question is if the -fast flag is good for postgres. The
-fast flag sets brutal floating point optimization and some
operation should have less precision. Is possible verify that
floating point
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
The problem was generated, because -fast option was set only for the
compiler and not for the linker. Linker takes wrong version of
libraries. If -fast is set for both then horology test is OK, but
question was if float
Postgres has own implementation of qsort. It is used only for Solaris,
because in some cases Solaris implementation was terrible slow.
Now, New qsort is present in the Solaris from version 9 update 6 and I
performed some quick test and the speed is very similarly with pg
implementation see
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Is it time to remove PG qsort and use libc version for solaris 9, 10...?
I have no particular desire to introduce a version number check until we
have to. If you can show that the newer versions have a qsort that
substantially *out
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Given the time that has been spent working around
the braindamaged behavior of qsort() on various platforms, I would be
more inclined to *always* use our qsort() instead of the platform's
version.
snip
I propose that we do the
Peter Eisentraut wrote:
Robert Treat wrote:
Also should installation.sgml
mention the issueswith building 32 vs 64 bit binaries
I'm not convinced there is an issue. dtrace will build the right
binaries by default. If you're messing with mixed environments *and*
delve into dtrace, you
Solaris had broken strtod function when parse Inf and Nan. See
solaris.h. This bug has been fixed for all current versions of Solaris (
8, 9, 10). See
http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-62-1searchclause=108993-62
Bruce Momjian wrote:
Zdenek Kotala wrote:
Solaris had broken strtod function when parse Inf and Nan. See
solaris.h. This bug has been fixed for all current versions of Solaris (
8, 9, 10). See
http://sunsolve.sun.com/search/document.do?assetkey=1-21-108993-62-1searchclause=108993-62
http
Zdenek Kotala wrote:
Alvaro Herrera wrote:
What's global? A maybe-useful flag would be telling that a table is
shared. Is that it? Mind you, it's not useful to me because I know
which tables are shared, but I guess for someone not so familiar with
the catalogs it could have some use
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
There is new version of catalogs overview patch. This version add only
one column into overview table which contains Oid/Filename for each
catalog table. Oid information is important if someone need make
relation with filename on disk
I updated FAQ_Solaris. I added new information related to Solaris 10,
rewrote optimalization hints and add information about dtrace. I talked
with Peter about Current maintainer role, and he said that this
information says anything and should be deleted.
Please, let me know your
Bruce Momjian napsal(a):
OK, great information, updated comment is:
/*
* Many versions of Solaris have broken strtod() --- see bug #4751182.
* This has been fixed in current versions of Solaris:
*
*
Martijn van Oosterhout napsal(a):
On Thu, Oct 05, 2006 at 04:39:22PM -0400, Mark Woodward wrote:
Indeed. The main issue for me is that the dumping and replication
setups require at least 2x the space of one db. That's 2x the
hardware which equals 2x $$$. If there were some tool which modified
Look at http://www.postgresql.org/docs/8.1/interactive/catalogs.html
Specially on pg_attribute, pg_class and pg_type table. Or you can use
some features in the psql.
Zdenek
Indira Muthuswamy napsal(a):
Hai,
Can anyone of you help me in finding the datatype of a particular column
Hi Heikki,
I'm sorry for lack of explanation. It is my fault.
Heikki says (on commit fest wiki):
I believe I debunked this patch enough already. Apparently there's some
compatibility issue between 32-bit and 64-bit Sparcs, but this patch
didn't catch that. It doesn't seem like
Zdenek Kotala napsal(a):
32/64 bit issue is little bit different story and it is general (not
only SPARC but on SPARC has bigger impact). Problem is that CRC32 gives
probably different result when it is compiled 32bit or 64bit. I'm going
to examine it more.
I'm sorry about noise
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
The original proposal
(http://archives.postgresql.org/message-id/[EMAIL PROTECTED])
contains two parts. First part is implementation of --footprint cmd
line switch which shows you page layout structures footprint. It is
useful
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
Upps, I'm sorry I'm going to fix it and I will send new version asap.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql
Gregory Stark napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Hmm, good question. For example ZFS is platform independent, you can take disk
from SPARC machine and plug it into x86 and ZFS works perfectly.
FWIW as far as I know *all* filesystems are platform independent. (Of course
now
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
snip
AFAICS you can get all the same information from pg_controldata. We have
a pretty good idea of the alignments of all the usual platforms anyway.
If someone says in a bug report that they're running
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which
actual information there. I'm going to do soon.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
but pg_upgrade.sh script worked fine in May without any
modification for conversion 8.3-8.4.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
because of that. Neither will the FSM
rewrite. Not sure about DSM yet.
Does it mean, that if you inject old data file after catalog upgrade, then FSM
will works without any problem?
Zdenek
PS: I plan to review FSM this week.
--
Zdenek Kotala Sun Microsystems
catalog conversion.
Another idea is to create backward compatible AM and put them into separate
library. If these AM will work also with old page structure then there should
not be reason for reindexing or index page conversion after upgrade.
Zdenek
--
Zdenek Kotala
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release
to implement upgrade-in-place. There's
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you inject old
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
Another idea is to create backward compatible AM and put them into separate
library. If these AM will work also with old page structure then there should
not be reason for reindexing or index page conversion after upgrade.
I don't
Heikki Linnakangas napsal(a):
Design functionality changes left:
- move retrieveing collation from pg_database to pg_type
The problem there is that pg_collation is local catalog, but pg_database
is global catalog. IIRC, It was discussed during last commitfest. I
think it is bad idea to
I has played with new hash index implementation and I tried following
command:
postgres=# select * from test where id between 1 and 5;
Time: 9651,033 ms
postgres=# explain select * from test where id between 1 and 5;
QUERY PLAN
Hannu Krosing napsal(a):
On Wed, 2008-09-10 at 07:13 -0400, Robert Haas wrote:
I'm not planner guru but it seems to me that BETWEEN clause could be
rewritten as a IN clause for integer data types and small interval.
Where should the line be drawn.
Define small :)
When the estimated cost is
Heikki Linnakangas napsal(a):
Here's an updated FSM patch. Changes since last patch:
Yesterday, I started to reviewing your patch. At the beginning I have
general questions:
1) If I understand correctly the main goal is to improve FSM to cover
all pages in file which is useful for huge
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Do you still have the iGen setup available? Want to give it a shot?
Not sure if I have it configured, need to check. But I'll try it or I'll ask
Jignesh or Paul if they have a free time. They are real benchmark gurus
extra note in fsm_internal.h about it
could be helpful.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
for firstime modified page.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Gregory Stark napsal(a):
Heikki Linnakangas [EMAIL PROTECTED] writes:
snip
AFAIK we can't easily connect to the new database and do some fiddling with
it, can we? If we could we could check if there are any non-empty indexes
which depend on the collation and only print the warning if we
Heikki Linnakangas napsal(a):
Martijn van Oosterhout wrote:
On Wed, Sep 10, 2008 at 12:51:02PM +0300, Heikki Linnakangas wrote:
Since the set of collations isn't exactly denumerable, we need some way
to allow the user to specify the collation they want. The only
collation PostgreSQL knows
to preserve lock numbers. It helps to DTrace
script be more backward compatible.
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Heikki Linnakangas napsal(a):
Heikki Linnakangas wrote:
snip
Let me describe this test case first:
- The test program calls RecordAndGetPageWithFreeSpace in a tight loop,
with random values. There's no activity to the heap. In normal usage,
the time spent in RecordAndGetWithFreeSpace is
.
It clash with hash index patch which was committed four days ago. Try to use
little bit older revision from git (without hash index modification).
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers
.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Suggestions:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Probably only we need full page write on first modification after
checkpoint.
Hmm, we don't
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I'll try something but I do not guarantee result.
Zdenek
--
Zdenek Kotala Sun Microsystems
Heikki Linnakangas napsal(a):
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Thanks. That's very disappointing :-(
One thing that jumped out at me is that you call
http://kenai.com/
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test was surprise for me. I run original
server (with old
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Zdenek Kotala napsal(a):
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
My conclusion is that new implementation is about 8% slower in OLTP
workload.
Can you do some analysis of why that is?
I tested it several times and last test
Martijn van Oosterhout napsal(a):
On Mon, Sep 22, 2008 at 06:11:04PM +0300, Heikki Linnakangas wrote:
This patch should allow to use both system catalog and ICU.
Not without another patch that actually introduces ICU support. What
that would look like, how that would be stored in the catalogs,
Greg Smith napsal(a):
On Mon, 22 Sep 2008, Gregory Stark wrote:
I'm quite surprised Solaris doesn't support posix_fadvise -- perhaps
it's in some other version of Solaris?
Solaris has only fake variant of posix_fadvise. See
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
pg_collation catalog is also important for pg_dump, because system
collation names are not compatible over OS and pg_dump output should
be portable. pg_collation adds abstract layer which solve this problem.
That's a valid point. We'll still
, does anyone have other
ideas?
What's about truncate FSM during WAL replay of main fork truncation record?
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Heikki Linnakangas napsal(a):
Attached is a revamped version of the FSM rewrite. WAL-logging is now
gone. Any inconsistencies between levels of the FSM is fixed during
vacuum, and by searchers when they run into a dead end because of a
discrepancy. Corruption within FSM pages is likewise fixed
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
I'm testing this version now and I got core dump in initdb phase:
08047558 pgstat_count_heap_insert+0x20(840b120, 842d738, 80, 8047580)
snip
Let me know if you need more info. (I'm not using fresh CVS snapshot
but two weeks old
Gevik Babakhani napsal(a):
Dear PG hackers,
Has there been any idea to port PG to a more modern programming language
like C++? Of course there are some minor obstacles like a new OO design,
this being a gigantic task to perform and rewriting almost everything etc...
I am very interested to hear
Gevik Babakhani napsal(a):
Better idea is to start to use C99 in PostgreSQL ;-).
I have not investigated this yet. But I am very interested to know what the
advantages would be to upgrade the code to C99 standards.
I think replace macros with inline functions. It brings to ability to
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Attached is a new version, now with WAL-logging of the FSM truncation. I
decided to go with the separate WAL record for that, rather than
piggybacking on the smgrtruncate's WAL record. It seems much better from
a modularity point of view
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
snip
I've also tried various pgbench tests, on a RAM disk and otherwise, as
well as the table population test I ran earlier, and don't see any
difference in performance.
I think performance is OK
Zdenek
--
Sent via
from others.
thanks Zdenek
Regards
Abbas
On Fri, 2008-09-19 at 14:28 +0200, Zdenek Kotala wrote:
thanks
Abbas napsal(a):
Even with that a hunk failed for bufpage.c, but I applied that part
manually to move on.
Regards
Abbas
On Thu, 2008-09-18 at 12:17 +0200, Zdenek Kotala
. And good to mention that it is not
optimized version. It would be good if somebody will run different performance
test on it and verify my results.
I used iGen OLTP test with 60 concurrent users and run it for 30minutes.
Zdenek
--
Zdenek Kotala Sun Microsystems
Abbas napsal(a):
On Mon, 2008-09-29 at 14:42 +0200, Zdenek Kotala wrote:
Do I have to perform performance tests too?
Yes, please. My colleague tested it and got 5% performance drop, but it was not
complete version and I tested full patch on Friday and It was surprise for me
... I got
to think when the FSM
should be updated during WAL replay. Probably not after every record,
because of the overhead, but certainly more often than never.
What's about after a page write during a WAL replay?
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech
I attach patch which cleans up code around PageGetTempPage. These changes were
discussed here:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00102.php
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
diff
1 - 100 of 699 matches
Mail list logo
