Re: [PATCHES] two-phase commit

2003-10-23 Thread Heikki Linnakangas
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?

Re: [PATCHES] Two-phase commit

2004-03-26 Thread Heikki Linnakangas
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

[PATCHES] ipcrm or ipcclean hint

2005-01-03 Thread Heikki Linnakangas
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

[PATCHES] Refactoring lock.c

2005-02-02 Thread Heikki Linnakangas
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

Re: [PATCHES] Refactoring lock.c

2005-02-03 Thread Heikki Linnakangas
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

[PATCHES] Harmless space allocation typo

2005-03-05 Thread Heikki Linnakangas
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

[PATCHES] Cleaning up unreferenced table files

2005-03-05 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-03-05 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-04-26 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-04-26 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-04-27 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-04-27 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-04-27 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-04-28 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-05-06 Thread Heikki Linnakangas
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

Re: [PATCHES] Cleaning up unreferenced table files

2005-05-07 Thread Heikki Linnakangas
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 -

Re: [PATCHES] lastval()

2005-05-10 Thread Heikki Linnakangas
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

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Heikki Linnakangas
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

Re: [PATCHES] Post-mortem: final 2PC patch

2005-06-18 Thread Heikki Linnakangas
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

Re: [PATCHES] limiting connections per user/database

2005-06-26 Thread Heikki Linnakangas
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

[PATCHES] psql tab-completion for COMMIT/ROLLBACK PREPARED

2005-07-01 Thread Heikki Linnakangas
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

Re: [PATCHES] psql tab-completion for COMMIT/ROLLBACK PREPARED

2005-07-01 Thread Heikki Linnakangas
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

[PATCHES] Page at a time index scan

2006-05-02 Thread Heikki Linnakangas
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:

Re: [PATCHES] Page at a time index scan

2006-05-02 Thread Heikki Linnakangas
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

Re: [PATCHES] Page at a time index scan

2006-05-03 Thread Heikki Linnakangas
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

Re: [PATCHES] Page at a time index scan

2006-05-03 Thread Heikki Linnakangas
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

Re: [PATCHES] Page at a time index scan

2006-05-04 Thread Heikki Linnakangas
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

Re: [PATCHES] Page at a time index scan

2006-05-05 Thread Heikki Linnakangas
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.

Re: [PATCHES] Page at a time index scan

2006-05-06 Thread Heikki Linnakangas
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

[PATCHES] Maintaining cluster order on insert

2006-08-09 Thread Heikki Linnakangas
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

Re: [PATCHES] Maintaining cluster order on insert

2006-08-10 Thread Heikki Linnakangas
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

Re: [PATCHES] [HACKERS] Maintaining cluster order on insert

2006-08-11 Thread Heikki Linnakangas
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

[PATCHES] Merge join performance

2006-08-23 Thread Heikki Linnakangas
, 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

[PATCHES] currentItemData refactoring

2006-09-12 Thread Heikki Linnakangas
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

Re: [PATCHES] [HACKERS] Incrementally Updated Backup

2006-09-19 Thread Heikki Linnakangas
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

[PATCHES] Phantom Command IDs

2006-09-28 Thread 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

Re: [PATCHES] [GENERAL] ISO week dates

2006-10-12 Thread Heikki Linnakangas
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

[PATCHES] WAL logging freezing

2006-10-24 Thread Heikki Linnakangas
, 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

Re: [PATCHES] WAL logging freezing

2006-10-27 Thread Heikki Linnakangas
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

Re: [PATCHES] WAL logging freezing

2006-10-30 Thread Heikki Linnakangas
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

Re: [PATCHES] WAL logging freezing

2006-10-30 Thread Heikki Linnakangas
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

Re: [HACKERS] [PATCHES] WAL logging freezing

2006-10-31 Thread Heikki Linnakangas
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

Re: [PATCHES] WIP patch for tuple freezing issues

2006-11-05 Thread Heikki Linnakangas
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

Re: [PATCHES] On-disk bitmap index implementation

2006-12-04 Thread Heikki Linnakangas
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

Re: [PATCHES] ECPG docs

2006-12-04 Thread Heikki Linnakangas
: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

Re: [PATCHES] On-disk bitmap index implementation

2006-12-04 Thread Heikki Linnakangas
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

[PATCHES] Index split WAL reduction

2006-12-05 Thread Heikki Linnakangas
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

Re: [PATCHES] On-disk bitmap index implementation

2006-12-05 Thread Heikki Linnakangas
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

Re: [PATCHES] Enums patch v2

2006-12-19 Thread Heikki Linnakangas
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

Re: [PATCHES] On-disk bitmap index implementation

2006-12-27 Thread Heikki Linnakangas
/16388 I haven't dug deeper yet. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend

Re: [PATCHES] Index split WAL reduction

2007-01-02 Thread Heikki Linnakangas
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

[PATCHES] Last infomask bit

2007-01-05 Thread Heikki Linnakangas
. 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

Re: [pgsql-patches] [HACKERS] [PATCHES] Last infomask bit

2007-01-10 Thread Heikki Linnakangas
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

Re: [pgsql-patches] [HACKERS] [PATCHES] Last infomask bit

2007-01-10 Thread Heikki Linnakangas
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

Re: [pgsql-patches] [HACKERS] [PATCHES] Last infomask bit

2007-01-11 Thread Heikki Linnakangas
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

[pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-01-16 Thread 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

Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-01-16 Thread Heikki Linnakangas
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

[pgsql-patches] Phantom Command IDs, updated patch

2007-01-30 Thread Heikki Linnakangas
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

Re: [PATCHES] [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

2007-02-03 Thread Heikki Linnakangas
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

Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-05 Thread Heikki Linnakangas
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

Re: [PATCHES] [HACKERS] Dead code in _bt_split?

2007-02-08 Thread Heikki Linnakangas
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

Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Heikki Linnakangas
, 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

[PATCHES] Forbid finishing a prepared transaction from another database

2007-02-13 Thread Heikki Linnakangas
, 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

Re: [PATCHES] further bootstrap cleanup

2007-02-18 Thread Heikki Linnakangas
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

Re: [PATCHES] further bootstrap cleanup

2007-02-19 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-02-19 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-02-23 Thread Heikki Linnakangas
: 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

[PATCHES] Split _bt_insertonpg to two functions

2007-02-26 Thread Heikki Linnakangas
, 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

Re: [PATCHES]

2007-02-27 Thread Heikki Linnakangas
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

Re: [PATCHES] HOT WIP Patch - version 3.2

2007-02-27 Thread Heikki Linnakangas
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

[PATCHES] A little COPY speedup

2007-03-01 Thread Heikki Linnakangas
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

Re: [PATCHES] A little COPY speedup

2007-03-01 Thread Heikki Linnakangas
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

Re: [PATCHES] A little COPY speedup

2007-03-01 Thread Heikki Linnakangas
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

Re: [PATCHES] A little COPY speedup

2007-03-01 Thread Heikki Linnakangas
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

[PATCHES] Trivial comment fix

2007-03-05 Thread Heikki Linnakangas
-- 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

Re: [PATCHES] [HACKERS] Aggressive freezing in lazy-vacuum

2007-03-05 Thread Heikki Linnakangas
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

[PATCHES] Doc update, CLUSTER is not MVCC-safe

2007-03-09 Thread Heikki Linnakangas
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

Re: [PATCHES] scan_recycle_buffers

2007-03-09 Thread Heikki Linnakangas
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

Re: [PATCHES] Updated bitmap index patch

2007-03-12 Thread Heikki Linnakangas
? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Re: [PATCHES] Bitmapscan changes

2007-03-12 Thread Heikki Linnakangas
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

Re: [PATCHES] Bitmapscan changes

2007-03-12 Thread Heikki Linnakangas
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

Re: [PATCHES] Bitmapscan changes

2007-03-12 Thread Heikki Linnakangas
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

Re: [PATCHES] Bitmapscan changes

2007-03-12 Thread Heikki Linnakangas
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

Re: [PATCHES] Bitmapscan changes

2007-03-12 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-03-13 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-03-13 Thread Heikki Linnakangas
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

[PATCHES] Make CLUSTER MVCC-safe

2007-03-20 Thread Heikki Linnakangas
. 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

Re: [PATCHES] Improvement of procArray.xmin for VACUUM

2007-03-24 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-03-27 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-03-27 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-03-27 Thread Heikki Linnakangas
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

Re: [PATCHES] Recalculating OldestXmin in a long-running vacuum

2007-03-27 Thread Heikki Linnakangas
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

Re: [PATCHES] Numeric patch to add special-case representations for 8 bytes

2007-03-27 Thread Heikki Linnakangas
? 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

Re: [PATCHES] LIMIT/SORT optimization

2007-03-28 Thread Heikki Linnakangas
- #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

Re: [PATCHES] [PATCH] add CLUSTER table ORDER BY index

2007-03-28 Thread Heikki Linnakangas
? -- 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

Re: [PATCHES] [PATCH] add CLUSTER table USING index (take 2)

2007-03-29 Thread Heikki Linnakangas
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

Re: [PATCHES] Make CLUSTER MVCC-safe

2007-03-29 Thread Heikki Linnakangas
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

Re: [PATCHES] Small addition to PGInterval

2007-03-29 Thread Heikki Linnakangas
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

Re: [PATCHES] Make CLUSTER MVCC-safe

2007-03-30 Thread Heikki Linnakangas
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

Re: [PATCHES] DEALLOCATE ALL

2007-04-01 Thread Heikki Linnakangas
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   2   3   4   >