[PATCHES] DDL in EDB-SPL

might've guessed, kind of. TEMPORARY is stripped away, leaving just CREATE TABLE tablename. However, we've set the package namespace as the special namespace, and that's the current default creation namespace. Therefore the table gets created inside the package namespace. -- Heikki Linnakangas

Re: [PATCHES] DDL in EDB-SPL

Pavel Stehule wrote: Wrong address :) Shit! I knew this was going to happen eventually, because when I start to type pa... in the address bar, [EMAIL PROTECTED] is the first hit... Sorry for the noise, please ignore... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com

[PATCHES] tzcode update

there to be some failures now that we support timezones for timestamps outside the 32-bit time_t range. Apparently our tests don't cover that? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com pg-tzcode2007k.patch.gz Description: GNU Zip compressed data

Re: [PATCHES] Endless recovery

: +15 -13; Fix thinko in gistRedoPageUpdateRecord: if XLR_BKP_BLOCK_1 is set, we don't have anything to do to the page, but we still have to adjust the incomplete_inserts list that we're maintaining in memory. Teodor, what do you think? -- Heikki Linnakangas EnterpriseDB http

Re: [PATCHES] Endless recovery

. -- 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 message can get through

Re: [PATCHES] tzcode update

4800 a waste of time. Am I missing something? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] tzcode update

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Looking closer, I don't understand how that change was supposed to do anything. The point of that patch is to avoid an off-by-one result for years BC. The direction of rounding in integer division with a negative numerator

Re: [PATCHES] tzcode update

, anyway. Yep, and PostgreSQL 8.4 won't be released for quite some time. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http

[PATCHES] CopyReadLineText optimization

to stop the efficient word-at-a-time scan that memchr does (at least with glibc, YMMV) whenever there's a column separator, while in CopyReadLineText you get to process the whole line in one call, assuming there's no backslashes. -- Heikki Linnakangas EnterpriseDB http

Re: [PATCHES] Fix for initdb failures on Vista

that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings

Re: [PATCHES] CopyReadLineText optimization

Heikki Linnakangas wrote: Attached is a patch that modifies CopyReadLineText so that it uses memchr to speed up the scan. The nice thing about memchr is that we can take advantage of any clever optimizations that might be in libc or compiler. Here's an updated version of the patch

[PATCHES] CopyReadAttributesCSV optimization

also doesn't look much worse after the patch, perhaps even better. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com Index: src/backend/commands/copy.c === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src

Re: [PATCHES] WIP: guc enums

: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain

Re: [PATCHES] WIP: guc enums

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Magnus Hagander wrote: On my platform (linux x86) it works fine when I just cast this to (int *), but I'm unsure if that's going to be safe on other platforms. I had some indication that it's probably not? No, I don't think that's

Re: [PATCHES] WIP: guc enums

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Tom Lane wrote: What I'd suggest is declaring the actual variable as int. You can still use an enum typedef to declare the values, and just avert your eyes when you have to cast the enum to int or vice versa. (This is legal per C

Re: [PATCHES] CopyReadLineText optimization

Heikki Linnakangas wrote: Heikki Linnakangas wrote: Attached is a patch that modifies CopyReadLineText so that it uses memchr to speed up the scan. The nice thing about memchr is that we can take advantage of any clever optimizations that might be in libc or compiler. Here's an updated

Re: [PATCHES] CopyReadLineText optimization

Andrew Dunstan wrote: Heikki Linnakangas wrote: Another update attached: It occurred to me that the memchr approach is only safe for server encodings, where the non-first bytes of a multi-byte character always have the hi-bit set. We currently make the following assumption in the code

Re: [PATCHES] CopyReadLineText optimization

aggressive inlining would help. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-patches

Re: [PATCHES] CopyReadLineText optimization

Andrew Dunstan wrote: Heikki Linnakangas wrote: Andrew Dunstan wrote: I'm still a bit worried about applying it unless it gets some adaptive behaviour or something so that we don't cause any serious performance regressions in some cases. I'll try to come up with something. At the most

Re: [PATCHES] CopyReadLineText optimization

Andrew Dunstan wrote: Heikki Linnakangas wrote: Andrew Dunstan wrote: I'm still a bit worried about applying it unless it gets some adaptive behaviour or something so that we don't cause any serious performance regressions in some cases. I'll try to come up with something. At the most

Re: [PATCHES] CopyReadAttributesCSV optimization

Andrew Dunstan wrote: Heikki Linnakangas wrote: Here's a patch to speed up CopyReadAttributesCSV. On the test case I've been playing with, loading the TPC-H partsupp table, about 20% CopyReadAttributesCSV (inlined into DoCopy, DoCopy itself is insignificant): [snip] The trick

Re: [PATCHES] CopyReadLineText optimization

| 00:00:05.654761 1/16 | 00:00:04.719027 none | 00:00:03.718361 (6 rows) Attached is the test script and patches I used, if someone wants to test this on another platform. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com Index: src/backend/commands/copy.c

Re: [PATCHES] [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

, but I doubt it's worth the code complexity, and calling repalloc with a larger than necessary size can actually force it to unnecessarily allocate a new, larger chunk instead of reusing the old one. Thoughts on that? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com Index

Re: [PATCHES] Bulk Insert tuning

the buffer pinned, not locked. In my experience, pinning is the more expensive part, with the lookup into the buffer lookup table. Locking isn't free either, of course, but just avoiding the pin+unpin would help a lot. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent

Re: [PATCHES] TransactionIdIsInProgress() cache

conclude that A aborted, while it actually committed. My proposal was basically to add an extra TransactionIdDidCommit call before the TransactionIdIsInProgress call, in the hope that it returns true and we can skip the rest. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] [PERFORM] Very slow (2 tuples/second) sequentialscan after bulk insert; speed returns to ~500 tuples/second aftercommit

Alvaro Herrera wrote: Heikki Linnakangas wrote: I couldn't let this case go, so I wrote a patch. I replaced the linked list with an array that's enlarged at AtSubCommit_childXids when necessary. Do you still need to palloc the return value from xactGetCommittedChildren? Perhaps you can

Re: [PATCHES] [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Elsewhere in our codebase where we use arrays that are enlarged as needed, we keep track of the allocated size and the used size of the array separately, and only call repalloc when the array fills up, and repalloc a larger than

Re: [PATCHES] [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

about SubTransactionIds. We're talking about real XIDs assigned to subtransactions. Subtransactions are assigned regular XIDs as well, just like top-level transactions. I can see where you were coming from with you suggestion now :-). -- Heikki Linnakangas EnterpriseDB http

Re: [PATCHES] [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

as the INSERTs or after a COMMIT. Well, may be I making simple things complicated ;-) I think so :-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] Consistent \d commands in psql

to the tab-completion table, such as comments and conversions. There's a bunch of merge conflicts in the diff. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] \password in psql help

it mean, anyway? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [BUGS] Incomplete docs for restore_command for hotstandby

. What's our policy wrt. back-patching doc changes? This seems applicable to older versions as well, but do we do that? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription

Re: [PATCHES] create language ... if not exists

it. And you add a new rule for CREATE LANGUAGE ... HANDLER ..., but forgot IF_P NOT EXISTS from the end of that. Looks like you couldn't decide which approach to take, and ended up doing a little bit of both ;-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql

Re: [PATCHES] create language ... if not exists

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: The way we've solved this problem for other CREATE commands is to add OR REPLACE option, instead of IF NOT EXISTS. We should do the same here. If we're willing to consider a solution that is specific to CREATE LANGUAGE (as opposed

Re: [PATCHES] Ordered Append WIP patch v1

to behave differently since we don't want it prefetching lots of records like FINAL_MERGE does, I don't think. Doesn't seem worthwhile. The heap management part of the patch is quite short. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list

Re: [PATCHES] Re: [BUGS] BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: On second thought, expanding AttrNumber to int32, wholesale, might not be a good idea, No, it wouldn't. For one thing it'd be a protocol break --- column numbers are int16 --- I wasn't planning to change that. and for another

Re: [PATCHES] Re: [BUGS] BUG #4070: Join more then ~15 tables let postgreSQL produces wrong data

or MaxTupleAttributeNumber (1664) in a result set or intermediate tuples, like the output of a sort node, at least you could join ridiculously wide tables like that as long as you project out enough columns. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql

Re: [PATCHES] Expose checkpoint start/finish times into SQL.

Theo Schlossnagle wrote: First whack at exposing the start and finish checkpoint times into SQL. Why is that useful? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription

Re: [PATCHES] Expose checkpoint start/finish times into SQL.

checkpoint) in the 8.3 cycle, but didn't do it in the end. Perhaps we should add that, after all? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PATCHES] Partial match in GIN

that in addition to a regular b-tree index, you could use those two indexes together for any LIKE expression. I wonder what the size and performance of that would be like, in comparison to the proposed GIN solution? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via

Re: [PATCHES] Improve shutdown during online backup

online backup mode. Or we can add another state, PM_WAIT_BACKUP, before PM_WAIT_BACKENDS, that allows new connections, and waits until the backup ends. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org

[PATCHES] Indexam API changes

the git patch. There was also discussion on adding support for candidate matches, mainly for GIT, but GiST could possibly also take advantage of that. If people think it's worth it, I can fix the bit-rot in the patch and work on it, but personally I don't think it is. -- Heikki Linnakangas

Re: [PATCHES] Partial match in GIN

like a hack around LIKE support in BTree. This support uses outflank ways missing regular one. You could satisfy '%foo%' using a regular and a reverse B-tree index, and a bitmap AND. Which is interestingly similar to the way you proposed to use a TIDBitmap within GIN. -- Heikki Linnakangas

Re: [PATCHES] Partial match in GIN

Alvaro Herrera wrote: Heikki Linnakangas wrote: Teodor Sigaev wrote: GIN speeds up '%foo%' too - which is impossible for btree. But I don't like a hack around LIKE support in BTree. This support uses outflank ways missing regular one. You could satisfy '%foo%' using a regular

Re: [PATCHES] Partial match in GIN

Alvaro Herrera wrote: Well, LIKE %foo% is supposed to match foo unanchored, but with a btree (or two btrees) you can only get 'foo' anchored to either end of the string (or both). Ah, true. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing

Re: [PATCHES] EXPLAIN progress info

of the tree, right? For a query that for example performs a gigantic sort, that would be 0 until the sort is done, which is not good. It's hard to come up with a single counter that's representative :-(. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches

Re: [PATCHES] Patch to add a feature to pg_standby

pg_standby, and does the custom action when pg_standby returns successfully. Or perhaps you could run the custom action in whatever script is copying the files to the directory. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql

Re: [PATCHES] pg_postmaster_reload_time() patch

been triggered since. Perhaps the function should be named to reflect that better. pg_configuration_load_time() ? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] plpgsql CASE statement - last version

, what does PL/SQL or PSM say about the type-compatibility of the CASE and the WHENs? We're very lenient in assignments, how should this behave? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make

Re: [PATCHES] GUC parameter cursors_tuple_fraction

set. It's relevant even assuming that the planner got the estimates spot on. Which plan is the best depends on whether the application can start processing the data as it comes in, or whether it's loading it all in memory first, for example. -- Heikki Linnakangas EnterpriseDB http

Re: [PATCHES] Verified fix for Bug 4137

until we've successfully read the checkpoint/restartpoint record and started the replay. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PATCHES] Verified fix for Bug 4137

). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Verified fix for Bug 4137

Simon Riggs wrote: On Tue, 2008-05-06 at 17:52 +0100, Heikki Linnakangas wrote: I didn't suggest that alphabetical sorting property is a new assumption; it sure isn't. The new assumption is that you never call ReadRecord() for record 0002 before you call it for record 0001 (before initializing

Re: [PATCHES] Verified fix for Bug 4137

of just not doing the cleanup? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Verified fix for Bug 4137

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Ok, that'll work. Committed, thanks. I changed the sanity check that xlogfname restore point into an Assert, though, because that's a sign that something's wrong. Shouldn't that Assert allow the equality case? Yes. Thanks. Hmm

Re: [PATCHES] create or replace language

shouldn't do that either. So do we want to replace any data (in my opinion only the validator is left) at all or just skip any error message? I think you should be able to change handler and validator functions, and the trusted flag. Or is there a reason to not allow that? -- Heikki Linnakangas

Re: [PATCHES] Map forks (WIP)

them together for now, but will separate them when the fork stuff is ripe for committing. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PATCHES] extend VacAttrStats to allow stavalues of different types

. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] GIN improvements

the buffers periodically. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] minor ts_type.h comment fix

Jan Urbański wrote: These should read TSQuery, not TSVector, no? Yep. Applied. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

[PATCHES] \timing on/off

\timing behave the same as \x. I also moved the help line from the External section into Formatting. I don't think \timing is external in the same sense as \cd or \! are. Rather, it controls the output, like \x or \pset options. -- Heikki Linnakangas EnterpriseDB http

Re: [PATCHES] \timing on/off

And here is the patch I forgot to attach. Heikki Linnakangas wrote: I started to look at David Fetter's patch to enable \timing on/off, in addition to toggling the mod with just \timing. I gather that the conclusion of the thread Making sure \timing is on, starting at: http

Re: [PATCHES] \timing on/off

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Here's a patch, based on David's patch, that turns timing into a \pset variable, and makes \timing an alias for \pset timing. This makes \timing behave the same as \x. This seems a bit random to me. AFAIR all of the \pset

Re: [PATCHES] Refactoring xlogutils.c

Teodor Sigaev wrote: - For the routines that need a fake, or lightweight, Relation struct anyway, there's a new function called XLogFakeRelcacheEntry(RelFileNode), that returns a palloc'd Relation struct. Is that fake structure applicable for ReadBuffer()? Yes. -- Heikki Linnakangas

Re: [PATCHES] Refactoring xlogutils.c

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Attached is an updated version of my patch to refactor the XLogOpenRelation/XLogReadBuffer interface, in preparation for the relation forks patch, and subsequently the FSM rewrite patch. The code motion in md.c looks fairly bogus

Re: [PATCHES] A GUC variable to replace PGBE_ACTIVITY_SIZE

between memcpy and strcpy lies would be nice. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] Hint Bits and Write I/O

, the active pages that matter are in the buffer cache, and so are the hint bits for those pages. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [PATCHES] extend VacAttrStats to allow stavalues of different types

rely on those preset values. Right. Updated patch attached. Thanks, committed. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [PATCHES] [HACKERS] odd output in restore mode

at the patch.) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] Better formatting of functions in pg_dump

moves the metadata stuff before the function body, leaving the whitespace as is (in newline-before style). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com *** src/bin/pg_dump/pg_dump.c --- src/bin/pg_dump/pg_dump.c *** *** 6775,6788 dumpFunc(Archive *fout

Re: [PATCHES][UPDATED] A GUC variable to replace PGBE_ACTIVITY_SIZE

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Another simple optimization occurred to me while looking at this: we should skip the memcpy/strcpy altogether if the BackendActivity slot is not in use. That seems like a good bet, you usually don't try to max out max_connections

Re: [PATCHES] EXPLAIN progress info

and loops is there for every query execution, even if you don't do explain analyze. I wouldn't be surprised if the overhead of the counters turns out to be a non-issue, but we'd have to see some testing of that. InstrEndLoop is the function we're worried about, right? -- Heikki Linnakangas

Re: [PATCHES] page macros cleanup

PageGetSpecialSize here. Much simpler, and doesn't assume that the special area is always at the end of page (not that I see us changing that anytime soon). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make

[PATCHES] Multi-column GIN

Dumb question: What's the benefit of a multi-column GIN index over multiple single-column GIN indexes? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] Relation forks FSM rewrite patches

Simon Riggs wrote: On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote: Here's an updated version of the relation forks patch, and an incremental FSM rewrite patch on top of that. The relation forks patch is ready for review. The FSM implementation is more work-in-progress still

Re: [PATCHES] page macros cleanup

- \ MAXALIGN(sizeof(HashPageOpaqueData)) - \ sizeof(ItemIdData)) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] page macros cleanup

Pavan Deolasee wrote: On Fri, Jul 4, 2008 at 3:37 PM, Heikki Linnakangas [EMAIL PROTECTED] wrote: I think this is the way it should be: #define HashMaxItemSize \ (BLCKSZ - \ SizeOfPageHeaderData - \ MAXALIGN(sizeof(HashPageOpaqueData)) - \ sizeof(ItemIdData

Re: [PATCHES] page macros cleanup

, but AFAICS the widest fields in HeapTupleHeaderData are 4-bytes wide, so it should be possible to get away with 4-byte alignment. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your

Re: [PATCHES] Relation forks FSM rewrite patches

Simon Riggs wrote: On Fri, 2008-07-04 at 12:27 +0300, Heikki Linnakangas wrote: Simon Riggs wrote: On Fri, 2008-06-27 at 19:36 +0300, Heikki Linnakangas wrote: Here's an updated version of the relation forks patch, and an incremental FSM rewrite patch on top of that. The relation forks patch

Re: [PATCHES] Relation forks FSM rewrite patches

, though, so that you could refresh FSM information for say 100 pages, or one FSM page, at a time. That would reduce the WAL traffic of a VACUUM significantly, though I'm not sure how significant that is to begin with. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent

Re: [PATCHES] Bug fix for pg_standby keepfiles calculation

Simon Riggs wrote: Fix minor bug in pg_standby, noted by Ferenc Felhoffer Applied, thanks. I couldn't find a bug report from Ferenc in the archives. Did he contact you personally? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list

Re: [PATCHES] page macros cleanup (ver 04)

Zdenek Kotala wrote: Pavan Deolasee napsal(a): On Fri, Jul 4, 2008 at 4:25 PM, Heikki Linnakangas [EMAIL PROTECTED] wrote: No, there's a itemsz = MAXALIGN(itemsz) call before the check against HashMaxItemSize. Ah, right. Still should we just not MAXALIGN_DOWN the Max size to reflect

Re: [HACKERS][PATCHES] odd output in restore mode

exclusive locking. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [HACKERS][PATCHES] odd output in restore mode

Andrew Dunstan wrote: Kevin Grittner wrote: Heikki Linnakangas [EMAIL PROTECTED] wrote: We really need a more reliable way of detecting that a file has been fully copied. In our scripts we handle this by copying to a temp directory on the same mount point as the archive

Re: [HACKERS][PATCHES] odd output in restore mode

Andrew Dunstan wrote: Heikki Linnakangas wrote: Andrew Dunstan wrote: - or maybe provide a .bat file or perl script that would work as na archive_command on Windows. We're not talking about archive_command. We're talking about the thing that copies files to the directory that pg_standby

Re: [HACKERS][PATCHES] odd output in restore mode

nice to require a Perl installation on Windows, just for a replacement of Copy. Would a simple .bat script work? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http

Re: [PATCHES] fixing bug in combocid.c

HeapTupleHeaderGetCmin to get cmin. That's all there is to my patch, but read on for more details. Yep. Patch committed. Thanks for the report! This is my first patch; I hope I did it right! You did well :-). No need to tar or gzip small patches like that, though. -- Heikki Linnakangas EnterpriseDB

Re: [PATCHES] WIP Join Removal

Simon Riggs wrote: On Tue, 2008-09-02 at 13:20 +0300, Heikki Linnakangas wrote: Simon Riggs wrote: It turns out that a join like this select a.col2 from a left outer join b on a.col1 = b.col1 where b.col2 = 1; can be cheaper if we don't remove the join, when there is an index on a.col1

Re: [PATCHES] WIP Join Removal

isn't always a win. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] WIP Join Removal

the thing with planner tricks like this. I think we'll eventually need some sort of tuning knob to control how hard the planner tries to apply different optimizations like that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches

Re: [PATCHES] WIP Join Removal

;-). -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] [HACKERS] TODO item: Implement Boyer-Moore searching (First time hacker)

Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: Also, it would be nice to use B-M(-H) for LIKE as well. Right offhand, that seems impossible, at least in patterns with %. Or were you thinking of trying to separate out the fixed substrings of a pattern and search for them with BMH

Re: [PATCHES] still alive?

send them to pgsql-hackers. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

<    1   2   3   4