[pgsql-patches] Ctid chain following enhancement

2007-01-26 Thread Pavan Deolasee
Attached is a patch which should marginally improve the ctid chain followin code path when current and the next tuple in the chain are in the same block. In the current code, we unconditionally drop pin of the current block without checking whether the next tuple is the same block or not. ISTM th

Re: [pgsql-patches] Ctid chain following enhancement

2007-01-27 Thread Pavan Deolasee
On 1/27/07, Tom Lane <[EMAIL PROTECTED]> wrote: It looks to me that you have introduced a buffer leak into heap_get_latest_tid ... I can't spot that. A previously pinned buffer is released at the start of the loop if we are moving to a different block. Otherwise, the buffer is released at al

Re: [pgsql-patches] Ctid chain following enhancement

2007-01-28 Thread Pavan Deolasee
On 1/28/07, Tom Lane <[EMAIL PROTECTED]> wrote: OTOH it might be cleaner to refactor things that way, if we were going to apply this. Here is a revised patch which includes refactoring of heap_get_latest_tid(), as per Tom's suggestion. Thanks, Pavan -- EnterpriseDB http://www.enterpris

[pgsql-patches] Lock compatibility matrix

2007-01-30 Thread Pavan Deolasee
I had this in a different form, but reworked so that it matches the doc patch that Teodor submitted earlier. I think it would be good to have this information in the lock.h file as well. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com lock-compatibility.patch Description: Binary

Re: [pgsql-patches] Lock compatibility matrix

2007-01-30 Thread Pavan Deolasee
On 1/30/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote: Pavan Deolasee wrote: > I had this in a different form, but reworked so that it matches the > doc patch that Teodor submitted earlier. I think it would be good to > have this information in the lock.h file as well. Why w

[PATCHES] HOT WIP Patch - version 2

2007-02-19 Thread Pavan Deolasee
Reposting - looks like the message did not get through in the first attempt. My apologies if multiple copies are received. This is the next version of the HOT WIP patch. Since the last patch that I sent out, I have implemented the HOT-update chain pruning mechanism. When following a HOT-update

Re: [PATCHES] [HACKERS] HOT WIP Patch - version 2

2007-02-20 Thread Pavan Deolasee
On 2/20/07, Hannu Krosing <[EMAIL PROTECTED]> wrote: Ühel kenal päeval, T, 2007-02-20 kell 12:08, kirjutas Pavan Deolasee: What do you do, if there are no live tuples on the page ? will this un-HOTify the root and free all other tuples in HOT chain ? Yes. The HOT-updated status of th

Re: [PATCHES] [HACKERS] HOT WIP Patch - version 2

2007-02-20 Thread Pavan Deolasee
On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: Pavan Deolasee wrote: > When following a HOT-update chain from the index fetch, if we notice that > the root tuple is dead and it is HOT-updated, we try to prune the chain to > the smallest possible length. To do that, th

Re: [PATCHES] [HACKERS] HOT WIP Patch - version 2

2007-02-20 Thread Pavan Deolasee
On 2/20/07, Tom Lane <[EMAIL PROTECTED]> wrote: "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > ... Yes. The HOT-updated status of the root and all intermediate > tuples is cleared and their respective ctid pointers are made > point to themselves. Doesn't

Re: [PATCHES] [HACKERS] HOT WIP Patch - version 2

2007-02-20 Thread Pavan Deolasee
On 2/20/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: Tom Lane wrote: > > "Recently dead" means "still live to somebody", so those tids better not > change either. But I don't think that's what he meant. I'm more > worried about the deadlock possibilities inherent in trying to upgrade a > buffe

[PATCHES] HOT WIP Patch - version 3.2

2007-02-24 Thread Pavan Deolasee
Please see the attached WIP HOT patch - version 3.2. It now implements the logic for reusing heap-only dead tuples. When a HOT-update chain is pruned, the heap-only tuples are marked LP_DELETE. The lp_offset and lp_len fields in the line pointer are maintained. When a backend runs out of free

Re: [PATCHES] HOT WIP Patch - version 3.2

2007-02-27 Thread Pavan Deolasee
On 2/27/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: Pavan Deolasee wrote: > - What do we do with the LP_DELETEd tuples at the VACUUM time ? > In this patch, we are collecting them and vacuuming like > any other dead tuples. But is that the best thing to do ? Since they d

Re: [PATCHES] A little COPY speedup

2007-03-01 Thread Pavan Deolasee
Heikki Linnakangas wrote: Attached is a fix for that. It adds a flag to each heap page that indicates that "there isn't any free line pointers on this page, so don't bother trying". Heap pages haven't had any heap-specific per-page data before, so this patch adds a HeapPageOpaqueData-struct

[PATCHES] Resending - HOT WIP Patch - version 4

2007-03-01 Thread Pavan Deolasee
Resending once again, all my previous attempts seems to have failed. Is there a limit on patch size on -patches as well ? Attached is a gzipped version. Hi All, Please see the version 4.0 of HOT WIP patch attached with the mail. ISTM that this version has one of the most radical changes inclu

Re: [PATCHES] Heap page diagnostic/test functions (WIP)

2007-03-05 Thread Pavan Deolasee
Simon Riggs wrote: I'll happily code it as functions or system cols or any other way, as long as we can see everything there is to see. With HOT, other useful information is about the line pointers. It would be cool to be able to print the redirection info, details about LP_DELETEd line poi

[PATCHES] HOT WIP Patch - Version 4.1

2007-03-07 Thread Pavan Deolasee
Please see the attached HOT WIP patch, version 4.1. There are not any significant changes since the version 4.0 patch that I posted a week back. This patch includes some optimizations for efficiently looking up LP_DELETEd tuples. I have used the recent changes made by Tom/Heikki which give us f

[PATCHES] HOT WIP Patch - Version 4.4

2007-03-13 Thread Pavan Deolasee
Please see the attached version 4.4 of HOT WIP patch. I have fixed couple of bugs in the earlier version posted. Other than that there are not any significant changes in the patch. The row-level fragmentation had a bug where we were unintentionally sorting the line pointers array more than once.

[PATCHES] HOT WIP Patch - Version 5.0

2007-03-20 Thread Pavan Deolasee
The version 5.0 of HOT WIP patch is attached. This fixes the VACUUM FULL issue with HOT. In all the earlier versions, I'd disabled VACUUM FULL. When we move the HOT-chain, we move the chains but don't carry the HOT_UPDATED or HEAP_ONLY flags and insert as many index entries as there are tuples

Re: [PATCHES] HOT WIP Patch - version 6.3

2007-04-04 Thread Pavan Deolasee
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: Your patch has been added to the PostgreSQL unapplied patches list at: Thanks Bruce. I would like to submit atleast one more revision which would include couple of TODOs mentioned in my last mail. I would also like to do some cleanup and co

Re: [HACKERS] [PATCHES] Optimized pgbench for 8.3

2007-04-07 Thread Pavan Deolasee
On 4/6/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote: BTW, is anybody working on enabling the fill factor to the tables used by pgbench? 8.3 will introduce HOT, and I think adding the feature will make it easier to test HOT. Please see if the attached patch looks good. It adds a new -F option w

Re: [PATCHES] [HACKERS] CIC and deadlocks

2007-04-10 Thread Pavan Deolasee
On 4/1/07, Tom Lane <[EMAIL PROTECTED]> wrote: Good point. I'm envisioning a procarray.c function along the lines of bool TransactionHasSnapshot(xid) which returns true if the xid is currently listed in PGPROC and has a nonzero xmin. CIC's cleanup wait loop would check this and ignore

Re: [PATCHES] [HACKERS] CIC and deadlocks

2007-04-11 Thread Pavan Deolasee
On 4/11/07, Tom Lane <[EMAIL PROTECTED]> wrote: [ itch... ] The problem is with time-extended execution of GetSnapshotData; what happens if the other guy lost the CPU for a good long time while in the middle of GetSnapshotData? He might set his xmin based on info you saw as long gone. You mi

Re: [PATCHES] Dead Space Map version 3 (simplified)

2007-04-12 Thread Pavan Deolasee
ostmaster.c:2614 #19 0x0820228b in ServerLoop () at postmaster.c:1214 #20 0x08201c66 in PostmasterMain (argc=3, argv=0x9ecdc50) at postmaster.c :967 #21 0x081a9e0b in main (argc=3, argv=0x9ecdc50) at main.c:188 -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT + MVCC-safe cluster conflict fix

2007-04-19 Thread Pavan Deolasee
will insert them all as normal cold updates. Thanks Heikki. We might need to tweak it a bit because I think I had made an assumption that heap_hot_fetch() should be called only on the root tuple. Anyways, would look at it. Thanks -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT Patch - Ready for review

2007-04-20 Thread Pavan Deolasee
On 4/19/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: What's the purpose of the "HeapScanHintPagePrune" mechanism in index builds? I lost track of the discussion on create index, is the it necessary for correctness? Its not required strictly for correctness, but it helps us prune the HOT

Re: [PATCHES] HOT patches

2007-05-07 Thread Pavan Deolasee
e step process and a failure after the first step will leave an invalid index behind. In this particular case, CIC fails because of duplicate keys. I did not deliberately fix the regression output to highlight this change. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] Concurrent psql patch

2007-05-18 Thread Pavan Deolasee
ing style already followed in that particular file. But few simple rules like having a single space around operators like '<', '+', '=' etc really makes the code more readable. Other examples are using parenthesis in a right manner to improve code readability. flag = (

Re: [PATCHES] Maintaining cluster order on insert

2007-05-21 Thread Pavan Deolasee
On 5/19/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: Ah, sorry about that. For some reason my source tree was checked out from the 8.2 branch, instead of CVS HEAD. I looked at the patch. Not that I am very comfortable with this part of the code, but nevertheless here are my comments:

Re: [PATCHES] Maintaining cluster order on insert

2007-05-21 Thread Pavan Deolasee
On 5/21/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote: On 5/19/07, Heikki Linnakangas <[EMAIL PROTECTED] > wrote: > > > Ah, sorry about that. For some reason my source tree was checked out > from the 8.2 branch, instead of CVS HEAD. > > I looked at the patch.

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-05-30 Thread Pavan Deolasee
inner loop something like: Tom has already expressed his unwillingness to add complexity without any proven benefits. Your suggestion though good would make the code more unreadable without much benefit since the function is not called very often. Thanks, Pavan -- Pavan Deolasee Enterprise

Re: [PATCHES] [pgsql-patches] Ctid chain following enhancement

2007-06-01 Thread Pavan Deolasee
On 6/2/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: OK, removed from 8.4 queue. I am OK with this, though I personally never felt that it complicated the code :-) Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT latest patch - version 8

2007-07-23 Thread Pavan Deolasee
define InvalidOffsetNumber ((OffsetNumber) 0) So I think we should be OK to use that to indicate redirect-dead pointers. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 11

2007-08-01 Thread Pavan Deolasee
On 8/1/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-08-01 at 14:36 +0530, Pavan Deolasee wrote: > > > BufferIsLockedForCleanup() should be named BufferIsAvilableForCleanup(). > There is no cleanup mode, what we mean is that there is only one pin; > the co

Re: [PATCHES] HOT patch - version 11

2007-08-02 Thread Pavan Deolasee
On 8/2/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote: > > > > On 8/2/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > > > > Maybe a nicer > > solution would be to have another version of ConditionalLockBuffer with > > three different return values:

Re: [PATCHES] HOT patch - version 11

2007-08-02 Thread Pavan Deolasee
On 8/2/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > > Pavan Deolasee wrote: > > Please see the attached version 11 of HOT patch > > Thanks! > > One wrinkle in the patch is how the ResultRelInfo-struct is passed to > heap_update, and on to heap_check_idxupdat

Re: [PATCHES] HOT patch - version 11

2007-08-07 Thread Pavan Deolasee
On 8/2/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote: > > > > > . It would also be better if we didn't emit a > > separate WAL record for defraging a page, if we also prune it at the > > same time. I'm not that worried about WAL usage in general, but that

Re: [PATCHES] HOT patch - version 14

2007-08-20 Thread Pavan Deolasee
y sense, does it? > > Counterexample: OID. > > > Right. Further, we allow creating indexes on system attributes. So we must support those. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 14

2007-08-30 Thread Pavan Deolasee
On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > Please see the version 14 of HOT patch attached. > > I expected to find either a large new README, or some pretty substantial > additions to existing R

Re: [PATCHES] HOT patch - version 14

2007-08-30 Thread Pavan Deolasee
On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > You are right - a new index might mean that an existing HOT chain > > is broken as far as the new index is concerned. The way we address > > that is by

Re: [PATCHES] HOT patch - version 14

2007-08-30 Thread Pavan Deolasee
On 8/31/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > Not if someone else releases lock before committing. Which I remind you > is a programming technique we use quite a lot with respect to the system > catal

Re: [PATCHES] HOT patch - version 14

2007-08-31 Thread Pavan Deolasee
On 8/31/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote: > > > > In fact, now that I think about it there is no other > fundamental reason to not support HOT on system tables. So we > can very well do what you are suggesting. > > On second thought, I wonder if t

Re: [PATCHES] HOT patch - version 14

2007-08-31 Thread Pavan Deolasee
e. Thanks, Pavan P.S. Next week is bad for me :-( I am on vacation on Thursday/Friday and for remaining days, I may not be able to spend extra cycles, apart from regular working hours. -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] Lazy xid assignment V4

2007-09-04 Thread Pavan Deolasee
; I haven't been able to follow the discussions here, but do I need to worry about its interaction with HOT ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] Lazy xid assignment V4

2007-09-04 Thread Pavan Deolasee
On 9/4/07, Florian G. Pflug <[EMAIL PROTECTED]> wrote: > > > I don't think so. The interactions should be pretty minimal. Thats good news! Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT documentation README

2007-09-04 Thread Pavan Deolasee
a solution that would work in all cases and yet not too complicated. My guess is any such solution will involve breaking the existing HOT chains. Right now we support one of the most common use case where a table is created, loaded with data and one or more indexes are created - all in the same

Re: [PATCHES] HOT documentation README

2007-09-04 Thread Pavan Deolasee
ce in the relation and trigger autovacuuum based on the percentage of dead space in the table. We don't have any mechanism to account for index bloat yet. Autoanalyze does not change. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-05 Thread Pavan Deolasee
at SELECT may occasionally do more work. But since we ensure that we do the extra work only when there is no contention on the page, ISTM that the downside is limited. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
taking exclusive lock before checking free space in heap_page_prune_defrag(). That might be unsafe, but we don't care if you occasionally skip the maintenance work (or do it a little early) Thanks, Pavan Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
ion. heap_page_prune_defrag() would be a no-op for subsequent SELECTs (PageIsPrunable() would be false until the next UPDATE) I think Heikki's recent test confirms this. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
also prune-defrag is vacuum lazy and vacuum full. But I assume we are not worried about these maintenance activities. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
om the results it seems that HOT is also doing well for read-mostly queries. In this particular example, the first SELECT after the 250 UPDATEs would have pruned all the dead tuples and reduced HOT chain to a single tuple. Hence the total time for subsequent SELECTs improved tremendously. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
ed up again and again in presence of a long running transaction are high enough to justify adding 4 bytes to page header. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
entire chain. So I don't see why CVS HEAD would do better than HOT in the above case. Net-net there will be equal number of index keys after the inserts. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
and 3 are marked ~LP_USED - the offset of 4 and 5 is unchanged At the end of defragmentation: - 4 and 5 are moved to the end of the page to create a larger contiguous free space in the page. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
eap tuples. Not that we can't handle them, but I am worried about making such changes right now unless we are sure about the benefits. We can always tune and tweak in 8.4 Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-10 Thread Pavan Deolasee
o keep them together for now. - Track the minimum xmin in the page header to avoid repeated (wasted) attempts to prune a Prunable page in the presence of long running transactions. We can save rest of the techniques for beta testing period or 8.4. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-11 Thread Pavan Deolasee
OT chain and hence can be removed. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-11 Thread Pavan Deolasee
On 9/11/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > Pruning removes intermediate dead tuples by marking their line pointers > > ~LP_USED and redirecting the root line pointer to the first > > live/

Re: [PATCHES] HOT patch - version 15

2007-09-11 Thread Pavan Deolasee
On 9/11/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote: > > > - Track the minimum xmin in the page header to avoid repeated > (wasted) attempts to prune a Prunable page in the presence of long running > transactions. > > I would actually think twice before even doing this

Re: [PATCHES] HOT patch - version 15

2007-09-11 Thread Pavan Deolasee
On 9/11/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > I would actually think twice before even doing this because this would > > lead to complete change in heap page structure and stop people from > > up

Re: [PATCHES] HOT documentation README

2007-09-11 Thread Pavan Deolasee
nflicting transactions before taking snapshot for building the index in the first phase. This arrangement guarantees that the snapshot used in the first phase would always satisfy tuples at the head of the existing HOT chains. At the same time, no new broken HOT chains are created while we are building the index because the new index (even though not yet ready) is consulted for all subsequent UPDATEs. Hope this helps. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT documentation README

2007-09-12 Thread Pavan Deolasee
e we run with exclusive lock on the table. But if we agree that there is no problem with pruning RD tuple preceding a DEAD tuple, we can actually prune that tuple as well. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT documentation README

2007-09-12 Thread Pavan Deolasee
hange this to follow HOT chain in analyze. Since we fetch using SnapshotNow, if there is a live tuple at the end of the chain, analyze would use that. Otherwise the tuple is considered as DEAD. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-12 Thread Pavan Deolasee
all we have them, we will have some mechanism to recover from it. Any other ideas ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT documentation README

2007-09-12 Thread Pavan Deolasee
prune everything including the latest DEAD tuple. That would let us take out the changes related to freezing. I also think that should let us remove the DEAD_CHAIN concept, but let me check. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT documentation README

2007-09-13 Thread Pavan Deolasee
On 9/12/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote: > > > One change that is worh mentioning > and discussing is that we don't follow HOT chains while fetching tuples > during > autoanalyze and autoanalyze would consider all such tuples as DEAD. > In the worst

Re: [PATCHES] HOT patch - version 15

2007-09-13 Thread Pavan Deolasee
i changed that when he did the initial refactoring, but not sure why. May be he wanted to make it more consistent. But I don't think its broken because we collect the offsets in one-based format in PageRepairFragmentation, WAL log in that format and redo the same way. Am I missing something ? Tha

Re: [PATCHES] HOT patch - version 15

2007-09-13 Thread Pavan Deolasee
to it tomorrow. Or we can just revert it back to zero-based offsets. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT patch - version 15

2007-09-13 Thread Pavan Deolasee
On 9/13/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > > > Never mind ... though my > suspicions would probably not have been aroused if anyone had bothered > to fix the comments. > > Yeah, my fault. I should have fixed that. Sorry about that. Thanks, Pavan -

Re: [PATCHES] HOT patch - version 15

2007-09-13 Thread Pavan Deolasee
D tuples in the chain will be pruned, and hence we can collect any DEAD tuple seen while pruning. I am not sure if I explain this well, may be I should post an example. Need to run now. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

[PATCHES] HOT add-on patch

2007-09-15 Thread Pavan Deolasee
. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com HOT-v15-16.patch.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster

Re: [PATCHES] HOT synced with HEAD

2007-09-16 Thread Pavan Deolasee
ot_search_buffer and index_getnext. But I trust your judgment. I also liked the way you reverted the API changes to various index build methods. I would test the patch tomorrow in detail. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] Latest README.HOT

2007-09-16 Thread Pavan Deolasee
that we are now comfortable with most of the other items. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT synced with HEAD

2007-09-16 Thread Pavan Deolasee
s like you have already put in a different mechanism to handle that. So we should be able to get rid of HEAPTUPLE_DEAD_CHAIN. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT synced with HEAD

2007-09-16 Thread Pavan Deolasee
are already finding that complex - with the redirected line pointers it might be even more complex. If you are worried about the WAL part, may be we can fix that some other way. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT synced with HEAD

2007-09-16 Thread Pavan Deolasee
tly, then we don't need that extra bitmap and can in fact set the line pointer unused immediately. Otherwise, as you rightly pointed out, we might break a chain before we prune it. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT synced with HEAD

2007-09-16 Thread Pavan Deolasee
runing. Defragmentation is a costly operation and we would want to prune as many chains before calling it. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT synced with HEAD

2007-09-17 Thread Pavan Deolasee
tuples, apply HeapTupleSatisfiesVacuum on the tuple before checking for HeapTupleIsHotUpdated, so we are fine. Or should we just check for XMIN_INVALID explicitly at those places ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT synced with HEAD

2007-09-17 Thread Pavan Deolasee
; sure how practical that is, and am not real inclined to try to do it > right now anyway ... I agree. I just wanted to leave a hint there that such a possibility exists if someone really wants to optimize, now or later. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [PATCHES] HOT version 18

2007-09-17 Thread Pavan Deolasee
the caller. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com *** src/backend/access/index/indexam.c 2007-09-18 11:59:26.0 +0530 --- src/backend/access/index/indexam.c 2007-09-18 11:52:36.0 +0530 *** *** 531,536 --- 531,537 Ite

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

2008-03-11 Thread Pavan Deolasee
sed representation once the array size grows beyond a limit. Thanks, Pavan -- Pavan Deolasee 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] TransactionIdIsInProgress() cache

2008-03-11 Thread Pavan Deolasee
ed */ >} > } > else > { > /* in-progress */ > } > I doubt if the transformation is correct. If xvac_committed is true, why would one even get into the else part ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- S

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

2008-03-12 Thread Pavan Deolasee
gested earlier ? Am I missing some normal scenario where it won't work well ? Thanks, Pavan -- Pavan Deolasee 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] [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit

2008-03-12 Thread Pavan Deolasee
stored in the array is 1 to 1000 and if we are searching for a number closer to 1000, we can break the array into parts instead of equal parts and then search. Well, may be I making simple things complicated ;-) Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Se

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

2008-03-12 Thread Pavan Deolasee
On Wed, Mar 12, 2008 at 11:03 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > Subtransactions are assigned regular > XIDs as well, just like top-level transactions. > Ah, got it now. I never noticed this before. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.e

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

2008-03-12 Thread Pavan Deolasee
gt; It's not that common to have hundreds of thousands of subtransactions to > begin with.. True. But thats the case we are trying to solve here :-) Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patche

[PATCHES] VACUUM Improvements - WIP Patch

2008-06-09 Thread Pavan Deolasee
than setting page_prune_xid). May be we should trigger pruning if we got a line pointer bloat in a page too. Please let me know comments/suggestions and any other improvements. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com VACUUM_second_scan-v5.patch.gz Description: GN

Re: [PATCHES] page macros cleanup

2008-07-03 Thread Pavan Deolasee
ith appropriate macros. Thanks, Pavan -- Pavan Deolasee 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

2008-07-04 Thread Pavan Deolasee
nk correct formula is: > > #define HashMaxItemSize(page) \ >(PageGetPageSize(page) - \ > ( MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData))+ \ >MAXALIGN(sizeof(HashPageOpaqueData)) \ > )\ > ) > > What do you think? > Yes. I think

Re: [PATCHES] page macros cleanup

2008-07-04 Thread Pavan Deolasee
the current limit (because of MAXALIGN), I don't see how existing hash indexes can have a larger item than the new limit. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to

Re: [PATCHES] page macros cleanup

2008-07-04 Thread Pavan Deolasee
sizeof(ItemIdData)) > I am wondering if this would fail for corner case if HashMaxItemSize happened to be unaligned. For example, if (itemsz < HashMaxItemSize < MAXALIGN(itemsz), PageAddItem() would later fail with a not-so-obvious error. Should we just MAXALIGN_DOWN the HashMaxItem

Re: [PATCHES] page macros cleanup

2008-07-04 Thread Pavan Deolasee
on the itemsz ? It's more academical though, so not a big deal. Thanks, Pavan -- Pavan Deolasee 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

2008-07-04 Thread Pavan Deolasee
On Fri, Jul 4, 2008 at 4:20 PM, Zdenek Kotala <[EMAIL PROTECTED]> wrote: > > > > By my opinion first place where tuple should be placed is: > > MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData)) > Tuple actually starts from the other end of the block. Thanks

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

2008-07-20 Thread Pavan Deolasee
o various people > can fairly easily come up with their own favoured modifications for > testing. > > I would suggest, let's have at least one tuning patch along with some tests and numbers, before we go ahead and commit anything. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http: