Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Where was it posted anyway?
>
> > Found it:
>
> >
> > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=200312010450.hB14ovH16330%40candle.pha.pa.us&rnum=8
>
> Thanks. The original patch is much olde
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Where was it posted anyway?
> Found it:
>
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=200312010450.hB14ovH16330%40candle.pha.pa.us&rnum=8
Thanks. The original patch is much older than I thought --- I was
looking
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > If I remember correctly, you didn't like the index routines reading the
> > tuple information, or something like that, but there was a performance
> > benefit for duplicate keys, so I think we should re-investigate this.
>
> I don't s
Bruce Momjian <[EMAIL PROTECTED]> writes:
> If I remember correctly, you didn't like the index routines reading the
> tuple information, or something like that, but there was a performance
> benefit for duplicate keys, so I think we should re-investigate this.
I don't see the actual patch either i
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where are we on this? It seems like a win to me.
>
> I thought it was a bad idea, although I no longer remember the details.
If I remember correctly, you didn't like the index routines reading the
tuple information, or something li
Here is more detail on the patch.
---
Manfred Koizar wrote:
> On Mon, 1 Dec 2003 00:02:54 -0500 (EST), Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
> >Tom Lane wrote:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> >> An
On Mon, 01 Dec 2003 13:32:10 -0500, Tom Lane <[EMAIL PROTECTED]> wrote:
>Manfred Koizar <[EMAIL PROTECTED]> writes:
>> comparetup_index() compares two IndexTuples. The structure
>> IndexTupleData consists basically of not much more than an ItemPointer,
>> and the patch is not much more than adding
Manfred Koizar <[EMAIL PROTECTED]> writes:
> comparetup_index() compares two IndexTuples. The structure
> IndexTupleData consists basically of not much more than an ItemPointer,
> and the patch is not much more than adding a comparison of two
> ItemPointers. So how does the patch introduce a new
On Mon, 1 Dec 2003 00:02:54 -0500 (EST), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> >> And if it doesn't help index
>> >> creation speed, at least the resulting index has better correlation.
... which has been shown by the example in
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> If qsort is to blame, then maybe this patch could help. It sorts
> >> equal key values on item pointer. And if it doesn't help index
> >> creation speed, at least the resulting index has better correlation.
>
> > I will try to appl
Patch removed from queue.
---
Manfred Koizar wrote:
> On Mon, 01 Sep 2003 08:46:09 -0400, Tom Lane <[EMAIL PROTECTED]>
> wrote:
> >[EMAIL PROTECTED] writes:
> >> it took 69 minutes to finish, 75% of this time was devoted to
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> If qsort is to blame, then maybe this patch could help. It sorts
>> equal key values on item pointer. And if it doesn't help index
>> creation speed, at least the resulting index has better correlation.
> I will try to apply it within the next 48 hour
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manfred Koizar wrote:
> On Mon, 01 Sep 20
On Sun, 07 Sep 2003 12:23:28 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>Maybe so, but it would degrade the performance in the unique-index case
>if we do it as the TODO is worded.
The patch would only hurt with a unique index, if there are lots of
duplicate tuples at CREATE INDEX time.
>My own o
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >>> * Order duplicate index entries by tid for faster heap lookups
> >
> >> I don't know why that TODO entry exists, but I think the idea is
> >> counterproductive.
>
> > I assume you are talking about a unique index
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> * Order duplicate index entries by tid for faster heap lookups
>
>> I don't know why that TODO entry exists, but I think the idea is
>> counterproductive.
> I assume you are talking about a unique index that probably only has a
> few
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assume this completes this TODO:
> > * Order duplicate index entries by tid for faster heap lookups
>
> I don't know why that TODO entry exists, but I think the idea is
> counterproductive. The existing btree code will tend to
17 matches
Mail list logo
