> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> So an inner indexscan for tab1 is definitely a possible plan.
>
> > Yes, that was my point, that a nested loop could easily be involved if
> > the joined table has a restriction. Is there a TODO item here?
>
> More like a "to investigate" --- I'm
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> So an inner indexscan for tab1 is definitely a possible plan.
> Yes, that was my point, that a nested loop could easily be involved if
> the joined table has a restriction. Is there a TODO item here?
More like a "to investigate" --- I'm not sold on t
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I realize only nested loop has this problem. Mergejoin and
> > Hashjoin actually would grab the whole table via sequential scan, so the
> > index is not involved, right?
>
> They'd grab the whole table after applying restriction clauses. An
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I realize only nested loop has this problem. Mergejoin and
> Hashjoin actually would grab the whole table via sequential scan, so the
> index is not involved, right?
They'd grab the whole table after applying restriction clauses. An
indexscan mig
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > However, assume tab2.col2 equals 3. I assume this would cause an index
> > scan because the executor doesn't know about the most common value,
> > right? Is it worth trying to improve that?
>
> Oh, I see: you are assuming that a nestloop join is be
Bruce Momjian <[EMAIL PROTECTED]> writes:
> However, assume tab2.col2 equals 3. I assume this would cause an index
> scan because the executor doesn't know about the most common value,
> right? Is it worth trying to improve that?
Oh, I see: you are assuming that a nestloop join is being done, an
expressed in this e-mail may not be
neccessarily the views of SOPAC.
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 16, 2000 9:45 AM
To: Jules Bean
Cc: Tom Lane; Alfred Perlstein; [EMAIL PROTECTED]
Subject: Re: [HACKERS] Performance on inserts
A
[ Charset ISO-8859-1 unsupported, converting... ]
> Could you add to the TODO:
>
> support of binary data (eg varbinary type)
>
> I think the above is not trivial, as I think the parser choques on \00 bytes
> at several levels...
bytea type works for inserting null: 'a\\000b'.
>
> I had a c
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What I am more concerned about is a join that uses the most common
> > value. We do an index scan in that case.
>
> No, we do whichever plan looks cheapest. Again, it's all about
> statistics.
>
> Right now, eqjoinsel() is just a stub that return
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What I am more concerned about is a join that uses the most common
> value. We do an index scan in that case.
No, we do whichever plan looks cheapest. Again, it's all about
statistics.
Right now, eqjoinsel() is just a stub that returns a constant
sel
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> * Prevent index lookups (or index entries using partial index) on most
> common values; instead use sequential scan
> >>
> >> This behavior already exists for the most common value, and would
> >> exist for any additional values that we had
Bruce Momjian <[EMAIL PROTECTED]> writes:
* Prevent index lookups (or index entries using partial index) on most
common values; instead use sequential scan
>>
>> This behavior already exists for the most common value, and would
>> exist for any additional values that we had stats for.
> > > * Prevent index lookups (or index entries using partial index) on most
> > > common values; instead use sequential scan
> >
> > This behavior already exists for the most common value, and would
> > exist for any additional values that we had stats for. Don't see
> > why you think a sepa
> > * Prevent index lookups (or index entries using partial index) on most
> > common values; instead use sequential scan
>
> This behavior already exists for the most common value, and would
> exist for any additional values that we had stats for. Don't see
> why you think a separate TODO it
> * Prevent index lookups (or index entries using partial index) on most
> common values; instead use sequential scan
This behavior already exists for the most common value, and would
exist for any additional values that we had stats for. Don't see
why you think a separate TODO item is needed
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Thomas Lockhart <[EMAIL PROTECTED]> writes:
What is the status of partial indices?
>>
>> They've been diked out of gram.y's syntax for CREATE INDEX at least
>> since Postgres95. No way to tell who did that, why or when, AFAIK.
>> There is still an
> Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> > One of MySQL's little syntax abuses allows:
> > INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..);
>
> Actually, that's perfectly standard SQL92, just an item we haven't
> got round to supporting yet. (Until we do the fabled querytree
> r
> > 98304 22.07 5545984
> > 196608 45.60 11141120
> > 393216 92.53 22290432
> >
> > I tried probabilities from 0.67 to 0.999 and found that runtimes didn't
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > What is the status of
> > partial indices? Are they functional now, or have they been broken
> > forever (I'm not recalling)?
>
> They've been diked out of gram.y's syntax for CREATE INDEX at least
> since Postgres95. No way to tell who did that,
19 matches
Mail list logo
