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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 = (
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:
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.
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
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
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
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
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:
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
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
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
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
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
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
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
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
;
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
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
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
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
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
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
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
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
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
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
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
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
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
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
OT chain and hence can be removed.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
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/
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
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
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
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
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
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
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
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
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
to it tomorrow.
Or we can just revert it back to zero-based offsets.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
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
-
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
.
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
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
that we are now comfortable with most of the other items.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
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
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
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
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
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
; 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
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
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
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
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
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
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
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
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
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
nk correct formula is:
>
> #define HashMaxItemSize(page) \
>(PageGetPageSize(page) - \
> ( MAXALIGN(SizeOfPageHeaderData + sizeof(ItemIdData))+ \
>MAXALIGN(sizeof(HashPageOpaqueData)) \
> )\
> )
>
> What do you think?
>
Yes. I think
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
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
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
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
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:
94 matches
Mail list logo