"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> CREATE INDEX
> CREATE INDEX CONCURRENTLY
> -
> I'm not very familiar with how these, so I'll just shut up..
Here is an addendum for how HOT handles CREATE INDEX and CREATE INDEX
CONCURRENTLY.
CREATE INDEX
There are two
On 7/15/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Actually
storing InvalidOffsetNumber in lp_off is a bit bogus in the first place
since lp_off is unsigned, and InvalidOffsetNumber is -1, so I fixed that
as well.
I see InvalidOffsetNumber as 0 in off.h:26
#define InvalidOffsetNumb
[EMAIL PROTECTED] wrote:
> Any objections to changing the name of "RedirectDead"? A RedirectDead
> ItemId is not really redirected, it's just a stub representing a dead
> tuple (the space for that tuple has been reused but an index entry may
> still point to the ItemId).
>
> How about "stub" or
> I'm looking for ways to make the patch simpler and less invasive.
Any objections to changing the name of "RedirectDead"? A RedirectDead
ItemId is not really redirected, it's just a stub representing a dead
tuple (the space for that tuple has been reused but an index entry may
still point to t
On Sun, 15 Jul 2007, Simon Riggs wrote:
Our main test case for OLTP is DBT-2 which follows TPC-C in being
perfectly scalable with no hot spots in the heap and limited hot spots
in the indexes. As such it's a poor test of real world applications,
where Benfold's Law holds true.
I assume this
On Fri, 2007-07-13 at 16:22 +0100, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > I have some suggestions which I'll post separately,
> I'm looking for ways to make the patch simpler and less invasive. We may
> want to put back some of this stuff, or come up with a more clever
> solu
Heikki Linnakangas wrote:
> Stefan Kaltenbrunner wrote:
>> tried to test a bit on my Solaris 10 install(sun studio , 64bit build)
>> but I'm hitting the following while trying to initdb a new cluster:
>
> I can't reproduce this error, but I found a bug that's likely causing
> it. The patch uses In
Stefan Kaltenbrunner wrote:
> tried to test a bit on my Solaris 10 install(sun studio , 64bit build)
> but I'm hitting the following while trying to initdb a new cluster:
I can't reproduce this error, but I found a bug that's likely causing
it. The patch uses InvalidOffsetNumber in lp_off to mark
Pavan Deolasee wrote:
>
> Please see updated version of the patch. This includes further code
> refactoring and bug fixes.
>
> heapam code is now refactored and I have also added several comments
> in that code as well as vacuum and create index related code.
>
> In the previous version, we were
Michael Glaesemann wrote:
On Jul 13, 2007, at 8:31 , Heikki Linnakangas wrote:
Row-level fragmentation
---
If there's no LP_DELETEd tuples large enough to fit the new tuple in,
the row-level fragmentation is repaired in the hope that some of the
slots were actually big en
Heikki,
Thanks for providing this summary. As someone unfamiliar with the
domain (both HOT development specifically and tuple management in
general), I found it easy to follow.
On Jul 13, 2007, at 8:31 , Heikki Linnakangas wrote:
Pruning
---
To reclaim the index-visible (i.e. first)
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A much simpler approach would be to try to acquire the vacuum lock, and
compact the page the usual way, and fall back to a cold update if we
can't get the lock immedia
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> A much simpler approach would be to try to acquire the vacuum lock, and
>>> compact the page the usual way, and fall back to a cold update if we
>>> can't get the lock immediatel
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A much simpler approach would be to try to acquire the vacuum lock, and
compact the page the usual way, and fall back to a cold update if we
can't get the lock immediately.
Seems like that could work.
I just realized that there'
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> A much simpler approach would be to try to acquire the vacuum lock, and
> compact the page the usual way, and fall back to a cold update if we
> can't get the lock immediately.
Seems like that could work.
> I'm looking for ways to make the patch
Heikki Linnakangas wrote:
I have some suggestions which I'll post separately,
A significant chunk of the complexity and new code in the patch comes
from pruning hot chains and reusing the space for new updates. Because
we can't reclaim dead space in the page like a VACUUM does, without
holdi
Pavan Deolasee wrote:
Please see updated version of the patch. This includes further code
refactoring and bug fixes.
Thanks for the update, Pavan!
I've been looking at this patch in the last couple of weeks in detail. I
wrote a short summary of how it works (attached) to help reviewing it.
E
17 matches
Mail list logo
