Stephan Szabo <[EMAIL PROTECTED]> writes:
> Well, if you want to be safer, I guess you could (at runtime) decide that
> the table's gotten too big and fall back to the old method if you didn't
> entirely rip it out. I'm not sure if that'd be too ugly though, but it
> would mean that you wouldn't h
On 22 Aug 2003, Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Finally, I suspect that once we get rid of the O(N^2) behavior in the
> > executor, we will find that the next biggest bottleneck is in the
> > planner; adding more work for it to do per OR-clause item will make
> > t
Tom Lane <[EMAIL PROTECTED]> writes:
> Finally, I suspect that once we get rid of the O(N^2) behavior in the
> executor, we will find that the next biggest bottleneck is in the
> planner; adding more work for it to do per OR-clause item will make
> things worse not better.
But time spent in the
On 21 Aug 2003 at 16:42, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Within the scope of the new hashed IN stuff I believe so in at least some
> > cases. I have a few million row table of integers where searching for
> > values IN (~1 values) takes longer than creating the
> I'm toying with the notion of ripping out that logic and instead
> building an in-memory hashtable of already-returned TIDs. This could
> theoretically run out of memory if the multiple indexscan returns enough
> tuples, but I think in practice that wouldn't happen because the planner
> wouldn't
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm toying with the notion of ripping out that logic and instead
>> building an in-memory hashtable of already-returned TIDs. This could
>> theoretically run out of memory if the multiple indexscan returns enough
>> tuples, but I think in
Tom Lane wrote:
I'm toying with the notion of ripping out that logic and instead
building an in-memory hashtable of already-returned TIDs. This could
theoretically run out of memory if the multiple indexscan returns enough
tuples, but I think in practice that wouldn't happen because the planner
wo
Manfred Koizar <[EMAIL PROTECTED]> writes:
> WHERE a = 1 OR a = 2
> are totally different things. In the latter case you don't have to
> check prior conditions because the conditions are mutually exclusive.
> Is this reasonably easy to find out at plan creation time?
Yeah, I know, but I see
Tom,
> I'm toying with the notion of ripping out that logic and instead
> building an in-memory hashtable of already-returned TIDs. This could
> theoretically run out of memory if the multiple indexscan returns enough
> tuples, but I think in practice that wouldn't happen because the planner
> wo
On Thu, 21 Aug 2003 16:42:20 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>The point is that given
> WHERE a = 1 OR b = 1
>you could create a plan that first indexscans on a, then indexscans on
>b --- but you mustn't return any tuples in the second scan that you
>already returned in the first.
On Thu, 21 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Within the scope of the new hashed IN stuff I believe so in at least some
> > cases. I have a few million row table of integers where searching for
> > values IN (~1 values) takes longer than creating the te
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Within the scope of the new hashed IN stuff I believe so in at least some
> cases. I have a few million row table of integers where searching for
> values IN (~1 values) takes longer than creating the temp table,
> copying into it and doing the in su
12 matches
Mail list logo
