Here is the second version of my two phase commit patch. Please see
the discussion at the hackers-list.
- Heikki
twophase2.diff.gz
Description: Binary data
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
I have again updated my two-phase commit patches. Only minor
modifications.
I haven't received any comments and there hasn't been any discussion on
the implementation, I suppose that nobody has given it a try. :(
There is still some rough edges, but I think it's good enough as a first
cut. I
Hi,
While playing around, I got the following error message:
--
FATAL: pre-existing shared memory block (key 5432001, ID 90898435) is
still in use
HINT: If you're sure there are no old server processes still running,
remove the shared memory block with the command ipcrm, or just delete
the
Hi,
There's two almost identical pieces of code in LockRelease and
LockReleaseAll that do the opposite of GrantLock.
Here's a small patch that replaces those pieces with a static UnGrantLock
function.
This is preparation for the two-phase commit patch, since that introduces
more calls to
On Thu, 3 Feb 2005, Neil Conway wrote:
On Wed, 2005-02-02 at 21:41 +0200, Heikki Linnakangas wrote:
There's two almost identical pieces of code in LockRelease and
LockReleaseAll that do the opposite of GrantLock.
Here's a small patch that replaces those pieces with a static UnGrantLock
function
Here's a tiny fix for a harmless typo in catalog.c:
Too much space is allocated for tablespace file path, I guess the
directory name used to be pg_tablespaces instead of pg_tblspc at some
point.
- HeikkiIndex: catalog.c
===
RCS
Here's a patch for the TODO item Remove unreferenced table files created by transactions
that were in-progress when the server terminated abruptly.
It adds a new function, CleanupStaleRelFiles, that scans through the data
directory and removes all table files that are not mentioned in pg_class
On Sat, 5 Mar 2005, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Here's a patch for the TODO item Remove unreferenced table files created by
transactions
that were in-progress when the server terminated abruptly.
xlog.c is a fairly random place to put that functionality. Didn't
On Mon, 25 Apr 2005, Bruce Momjian wrote:
Tom Lane wrote:
...
I think though that we ought to first consider the question of whether
we *want* this functionality. On reflection I'm fairly nervous about
the idea of actually deleting anything during startup --- seems like a
good recipe for turning
On Tue, 26 Apr 2005, Heikki Linnakangas wrote:
On Mon, 25 Apr 2005, Bruce Momjian wrote:
...
I guess I am happy with just reporting during startup like the patch
does now.
Ok. I'll fix the design issues Tom addressed earlier, add documentation, and
resubmit.
Here you go.
The new functionality
On Tue, 26 Apr 2005, Alvaro Herrera wrote:
You forgot the attachment?
Damn. It happens time after time...
- HeikkiIndex: doc/src/sgml/maintenance.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v
retrieving
On Tue, 26 Apr 2005, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I feel that crashes that leaves behind stale files are rare.
Indeed, and getting more so all the time ...
How so? Have changes been made in those parts of the code?
which makes me question the value of doing anything
On Wed, 27 Apr 2005, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Tue, 26 Apr 2005, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I feel that crashes that leaves behind stale files are rare.
Indeed, and getting more so all the time ...
How so? Have changes been
How embarrasing...
I hope it's all there now.
On Thu, 28 Apr 2005, Bruce Momjian wrote:
Uh, you forgot to add cleanup.h.
---
Heikki Linnakangas wrote:
On Tue, 26 Apr 2005, Alvaro Herrera wrote:
You forgot the attachment?
Damn
On Thu, 5 May 2005, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Applied.
Now that I've had a chance to look at it, this patch is thoroughly
broken. Problems observed in a quick review:
1. It doesn't work at all for non-default tablespaces: it will
claim that every file in such a
Maybe we should take a different approach to the problem:
1. Create new file with an extension to mark that it's not
yet committed (eg. 1234.notcommitted)
2. ...
3. Take CheckpointStartLock
4. Write commit record to WAL, with list of created files.
5. rename created file (1234.notcommitted -
On Mon, 9 May 2005, Dennis Bjorklund wrote:
The thing is that I don't care how it's implemented, it's the feature
itself that is more importent to decide if we want it or not. I'm sure the
code can be fixed so everybody is happy it in the end,
You could implement this on top of the current nextval
On Sat, 18 Jun 2005, Tom Lane wrote:
I've attached the 2PC patch as applied in case you want to have a look.
I did some fairly significant hacking on it, and I thought it'd be a
good idea to enumerate some of the changes:
I modified the in-memory data structure so that there is a separate
On Sat, 18 Jun 2005, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Can we figure out another way to solve the race condition? Would it
in fact be ok for the checkpointer to hold the TwoPhaseStateLock,
considering that it usually wouldn't be held for long, since usually
On Sun, 26 Jun 2005, Petr JelĂnek wrote:
Alvaro Herrera wrote:
Maybe you could make some checks against the shared array of PGPROCs
(procarray.c), for the per-database limit at least. Not sure about
per-user limit.
Thats good idea (I could maybe add userid to PGPROC struct too) but I think
On Fri, 1 Jul 2005, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support for it? 2PC is not something you normally do
interactively
Oh, just realized after Tom's reply that you were talking about help, not
tab-completion...
On Fri, 1 Jul 2005, Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help
Here's a patch that implements page at a time index scans discussed at
pgsql-hackers earlier. See proposal 1 at:
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01237.php
It passes regression tests, and there's no known bugs. There's
some minor issues I'd like to point out, though:
On Tue, 2 May 2006, Tom Lane wrote:
Agreed. The pin has two functions:
- keep the page from being moved out of the bufmgr - no need anymore
- stop a vacuum from removing the page - no need anymore. We'll not stop
on a removable row anymore, so no need.
At the moment, backward scan returns to
On Tue, 2 May 2006, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Tue, 2 May 2006, Tom Lane wrote:
Backwards scan may break this whole concept; are you sure you've thought
it through?
I think so. The patch doesn't change the walk-left code. Do you have
something specific
On Wed, 3 May 2006, Heikki Linnakangas wrote:
On Tue, 2 May 2006, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Tue, 2 May 2006, Tom Lane wrote:
Backwards scan may break this whole concept; are you sure you've thought
it through?
I think so. The patch doesn't change
On Wed, 3 May 2006, Tom Lane wrote:
Heikki, were you planning to make a round of revisions in the patch,
or is this as far as you wanted to take it?
Here's an updated patch. It's the same as the original, but merged with
the changes to the vacuum_cleanup API you committed, and some comment
On Fri, 5 May 2006, Tom Lane wrote:
I wrote:
BTW, I just realized another bug in the patch: btbulkdelete fails to
guarantee that it visits every page in the index. It was OK for
btvacuumcleanup to ignore pages added to the index after it starts,
but btbulkdelete has to deal with such pages.
On Fri, 5 May 2006, Tom Lane wrote:
I have a sketch of a solution that doesn't require any change in page
allocation behavior. Can anyone see any holes in this:
Looks good to me.
Assume that we have some way to recognize whether a page has been split
since the current btbulkdelete scan
While thinking about index-organized-tables and similar ideas, it
occurred to me that there's some low-hanging-fruit: maintaining cluster
order on inserts by trying to place new heap tuples close to other
similar tuples. That involves asking the index am where on the heap the
new tuple should
Jonah H. Harris wrote:
On 8/9/06, Tom Lane [EMAIL PROTECTED] wrote:
UPDATE tries to place the new tuple on the same page it's already
on.
I think he meant for INSERT.
Right. Update is indeed taken care of already.
One example where this would help would be a customer_history table that
Ron Mayer wrote:
In my case my biggest/slowest tables are clustered by zip-code (which
does a reasonable job at keeping counties/cities/etc on the
same pages too). Data comes in constantly (many records per minute, as
we ramp up), pretty uniformly across the country; but most queries
are
, without patch: 2.46 s
The results are pretty stable, within 0.1 s.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
mergejointest.sh
Description: application/shellscript
Index: src/backend/access/nbtree/nbtree.c
Here's a patch to remove currentItemData currentMarkpos from
IndexScanDesc, and add equivalent fields in access method specific
opaque structs for those access methods that need them. That makes the
index am API cleaner.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Simon Riggs wrote:
+
+ if (startupAfterRecovery)
+ ereport(ERROR,
+ (errmsg(recovery ends normally with startup_after_recovery=false)));
+
I find this part of the patch a bit ugly. Isn't there a better way to
exit than throwing an error that's not really an error?
--
Heikki Linnakangas
of the current top-level transaction
(TransactionIdIsCurrentTransactionId). But that doesn't work because we
don't consider aborted subtransactions as current. Using the infomask
bit seems more robust anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend
that we prefer context diffs.
Please resend the patch as a context diff, using diff -c or cvs diff
-c, so that it's easier to review.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9
, the older
version would interpret the freeze WAL records as dead tuple removals,
and remove live records. I would've liked to give freezing a new opcode,
but we've ran out of them (see htup.h).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/heap
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I would've liked to give freezing a new opcode,
but we've ran out of them (see htup.h).
Hardly ... we have plenty of unused rmgr id's still.
Good point.
The real issue that still has to be resolved is the interaction of all
something? Finding this many bugs makes me nervous...
Simon volunteered to make the clog changes for 3 because it's a PITR
related issue. I can write a patch/patches for the other changes if it
helps.
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's premature to start writing
patches until we've decided how this really needs to work.
Not logging hint-bit updates seems safe to me. As long as we have the
clog, the hint-bit is just a hint
seems safe
for PITR.
The only performance hit would be the clearing of xmax values of aborted
transactions, but that doesn't seem too bad to me because most
transactions commit.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
at conclusion of the vacuum.
*/
is not accurate. As discussed earlier, a crash is a problem even if clog
is not truncated by this vacuum, because relfrozenxid is updated anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
traffic.
There are still some things Jie and I have not gotten to yet:
o Improving VACUUM support -- currently, VACUUM FULL means REINDEX for
bitmaps. Heikki Linnakangas offered to work on this. Heikki, are you
still interested?
Yeah, I can look into that.
o Test WAL replay more thoroughly
:32:16 -
@@ -4665,7 +4665,7 @@
/para
para
- The preprocessed file can be compiled normally, for example:
+ The processed file can be compiled normally, for example:
programlisting
cc -c prog1.c
/programlisting
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote:
We need to give the indexam API some further thought. As you know, I've
been working on the Grouped Index Tuples stuff, which also requires
changes to the API to get full benefit. There's a bunch of functionality
I'd like to see:
* Support for streamed bitmaps, like
from 45MB to 33MB, or ~ 25%. Your mileage may
vary, depending on the tuple and key sizes, and the order of inserts.
Anyone see a problem with this?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/nbtree/nbtinsert.c
Gavin Sherry wrote:
o Improving VACUUM support -- currently, VACUUM FULL means REINDEX for
bitmaps. Heikki Linnakangas offered to work on this. Heikki, are you
still interested?
BTW vacuuming seems quite broken as it is:
[EMAIL PROTECTED]:~/pgsql.bitmap$ ~/pgsql.bitmap/bin/psql
encourages misuse of the feature.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
/16388
I haven't dug deeper yet.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
generated WAL traffic from 45MB to 33MB, or ~ 25%. Your mileage may
vary, depending on the tuple and key sizes, and the order of inserts.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
crashtest.sh
Description: application/shellscript
Index: src/backend/access/nbtree
.
Naturally, there's no point applying this before we actually need more
infobits, but it's good to be prepared.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/common/heaptuple.c
===
RCS
does log_temp_files have to do with
the bits on the tuple header?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
measurable difference, but I can do a pgbench run to
make sure.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http
on my laptop, with scaling factor 10, using pgbench
postgres -t 10 -v, with fsync and full_page_writes disabled to make
it CPU bound, while observing top to confirm that CPU usage was 100%
during the test.
I think that's enough performance testing for this patch.
--
Heikki Linnakangas
is recalculated in a vacuum every
100 pages. That's a quite arbitrary number, but feels like a good one to me.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/commands/vacuumlazy.c
===
RCS file
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
It seems to me that we could easily reclaim a bit more dead tuples in a
vacuum by recalculating the OldestXmin every now and then.
Doesn't this break relfrozenxid maintenance?
Not AFAICS. relfrozenxid is nowadays updated
the patch is ready. Please remove the PHANTOMCID_DEBUG define
and ifdef blocks before applying.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/common/heaptuple.c
===
RCS file: /home
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I have two runs of DBT-2, one with the patch and one without.
Patched:
autovac public.stock scans:1 pages:1285990(-0)
tuples:25303056(-2671265) CPU 95.22s/38.02u sec elapsed 10351.17 sec
Unpatched:
autovac public.stock
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I think the patch is ready. Please remove the PHANTOMCID_DEBUG define
and ifdef blocks before applying.
BTW, I don't care much for the terminology phantom cid ... there's
nothing particularly phantom about them, seeing they get onto
look ugly. camelCase or underscores
between words would be more readable, but I retained the old style for
the sake of consistency.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/nbtree/nbtinsert.c
, and
the delete_function call is now in the else-branch. Did you get that
right in your commit?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
, not the
database where the transaction ran originally. And there might be other
places that get confused as well.
It turned out to be even simpler than I imagined. :)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/transam/twophase.c
or helper process?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Here is a patch further cleaning up dummy process startup and the
bootstrap code itself a little.
Could we please call the dummy processes something else? Dummy
seems a bit belittling for such important things like bgwriter
Alvaro Herrera wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW I've got serious reservations about whether this bit is safe:
+ /* The table could've grown since vacuum started, and
there
+* might already
:
new_n_dead_tuples = n_dead_tuples_at_end - (n_dead_tuples_at_start +
tuples_removed_thanks_to_new_snapshot)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map
, checkpoint_segments = 10,
to remove any other variables.
It's not a huge difference, but it's worth having, and performance
wasn't the main motivation of the patch anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/nbtree/nbtinsert.c
not in alphabetical order anymore.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do
pgstat counter.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
without the patch, and 17.7 s with the patch applied. Your mileage may vary.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/heap/heapam.c
===
RCS file: /home/hlinnaka/pgcvsrepository/pgsql
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
be nice.
I'll post a patch along those lines.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
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
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/nbtree/nbtinsert.c
===
RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/nbtree/nbtinsert.c,v
retrieving revision 1.152
release cycle when we changed the clog
truncation point to depend on freeze limit.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating
in older branches.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/ref/cluster.sgml
===
RCS file: /home/hlinnaka/pgcvsrepository/pgsql/doc/src/sgml/ref/cluster.sgml,v
retrieving revision 1.40
for tiny tables with for example just 1 page. It
performs an lseek, which isn't free.
What happens if multiple backends choose overlapping sets of buffers to
recycle?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
The patch also adds support for candidate matches. An index scan can
indicate that the tuples it's returning are candidates, and the executor
will recheck the original scan quals of any candidate matches when the
tuple is fetched
definitely want to use a clustered
index as well.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
In the second place, this seems to
forever kill the idea of indexscans that don't visit the heap --- not
that we have any near-term prospect of doing that, but I know a lot of
people remain interested in the idea
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
In the second place, this seems to
forever kill the idea of indexscans that don't visit the heap --- not
that we have any near-term prospect of doing that, but I know a lot of
people remain
and the performance gain you
get from clustered indexes vanishes after a while.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Was this revisited?
Arranging the tests has taken me longer than I thought, but I now
finally have the hardware and DBT-2 set up. I just finished a pair of 2h
tests with autovacuum off, and continuous vacuum of the stock table. I'm
trying
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone.
As expected, the steady-state of the stock
.
The documentation doesn't anything about CLUSTER not being MVCC-safe, so
I suppose there's no need to touch the docs. I sent a doc patch earlier
to add a note about it, that doc patch should still be applied to older
release branches, IMO.
--
Heikki Linnakangas
EnterpriseDB http
many times within a transaction. We could also use it
to free entries in the new combocids hash table earlier (not that it's a
problem as it is, though).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I ran two 24h test runs with DBT-2, one with the patch and one without.
To get comparable, predictable results, I turned autovacuum off and run
a manual vacuum in a loop on the stock-table alone
Gregory Stark wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Yes, at least for now. I can't believe the patch actually hurts performance,
but I'm not going to spend time investigating it.
Isn't this exactly what you would expect? It will clean up more tuples so
it'll dirty more pages
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Bruce Momjian wrote:
So are you stopping work on the patch? I assume so.
Yes, at least for now. I can't believe the patch actually hurts
performance, but I'm not going to spend time investigating it.
Are we withdrawing
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Maybe we should keep this issue open until we resolve the vacuum WAL
flush issue? I can then rerun the same tests to see if this patch is a
win after that.
Sounds like a plan, if you are willing to do that.
Sure, just rerunning
? If there's
no-one accessing that information currently, there's no
backwards-compatibility issue. I think this is a non-issue.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list
- #endif. Are those
just leftovers that should be removed, or are things that still need to
finished and enabled?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
opt_class opt_validator
Is the placement of opt_cluster_using completely arbitrary? I'm not very
familiar with the parser, it really looks like those type-definitions
are in random order.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Here's an update, fixing conflict by Tom's recent commit of Simon's
patch to skip WAL-inserts when archiving is not enabled.
Heikki Linnakangas wrote:
This patch makes CLUSTER MVCC-safe. Visibility information and update
chains are preserved like in VACUUM FULL.
I created a new generic
to PostgreSQL server. Please send patches to
the JDBC driver to the pgsql-jdbc mailing list.
PS. Thanks for the patch!
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 7: You can help support
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Here's an update, fixing conflict by Tom's recent commit of Simon's
patch to skip WAL-inserts when archiving is not enabled.
Hmm, wouldn't it be better if the rewriteheap.c file was in
access/heap/ instead of commands/?
Yeah, maybe. I thought
hash_search(REMOVE) in a loop, which isn't the
most efficient way to do it, but clearly there's need for more ways to
empty a hash table.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze
1 - 100 of 393 matches
Mail list logo