Tom Lane, 28.08.2012 16:30:
In Oracle an index (entry) has the information about transactional visibility.
You sure about that?
Yes, although technically it's not the index *entry*, but the index *block*.
But the result is the same thing.
The visibility information is stored on data block le
Thomas Kellerer writes:
> Martijn van Oosterhout, 28.08.2012 10:02:
>> I'm not sure how oracle avoids the same issues:
>> - The index has no visibility information, so you can't tell if an
>> index entry refers to a row you can actually see in your session.
>> The visibility map might help here in
On Tue, Aug 28, 2012 at 6:04 AM, Craig Ringer wrote:
> On 08/28/2012 05:51 PM, Thomas Kellerer wrote:
>
>> Martijn van Oosterhout, 28.08.2012 10:02:
>>
>>> I'm not sure how oracle avoids the same issues:
>>> - The index has no visibility information, so you can't tell if an
>>>index entry ref
Craig Ringer, 28.08.2012 15:04:
In Oracle an index (entry) has the information about transactional visibility.
Wow. Doesn't that mean that indexes are insanely expensive to update,
since each index (and possibly also the table its self) needs
updating?
No, I don't think so.
It's the same me
On 08/28/2012 05:51 PM, Thomas Kellerer wrote:
Martijn van Oosterhout, 28.08.2012 10:02:
I'm not sure how oracle avoids the same issues:
- The index has no visibility information, so you can't tell if an
index entry refers to a row you can actually see in your session.
The visibility map m
Martijn van Oosterhout, 28.08.2012 10:02:
I'm not sure how oracle avoids the same issues:
- The index has no visibility information, so you can't tell if an
index entry refers to a row you can actually see in your session.
The visibility map might help here in the future.
In Oracle an ind
On Sun, Aug 26, 2012 at 11:01:31PM +0200, Thomas Kellerer wrote:
> I was inspired by this question on StackOverflow:
> http://stackoverflow.com/questions/12128501/fastest-way-to-count-the-rows-in-any-database-table/12128545#12128545
>
> Which shows Oracle's behaviour with an index scan for the cou
2012/8/26 Tom Lane :
> Pavel Stehule writes:
>> is possible use seqscan for index?
>
> No, not for a normal indexscan --- concurrent page splits would break
> it.
>
and what about seq scan for prefetch index - and processing should be
random, but over pages in cache?
Pavel
> VACUUM can do that,
Jeff Janes wrote on 26.08.2012 22:26:
The seq scan is estimated to use sequential reads, while the
index-only scan is estimated to use random reads (because the index is
scanned in logical order, not physical order).
Sounds like scanning the index in physical order would be an enhancement.
That
On Sun, Aug 26, 2012 at 12:58 PM, Thomas Kellerer wrote:
> Jeff Janes wrote on 26.08.2012 20:45:
>
>> The seq scan is estimated to use sequential reads, while the
>> index-only scan is estimated to use random reads (because the index is
>> scanned in logical order, not physical order).
>>
>> If yo
Jeff Janes wrote on 26.08.2012 20:45:
The seq scan is estimated to use sequential reads, while the
index-only scan is estimated to use random reads (because the index is
scanned in logical order, not physical order).
If you set random_page_cost equal to seq_page_cost, that would
artificially fav
Pavel Stehule writes:
> is possible use seqscan for index?
No, not for a normal indexscan --- concurrent page splits would break
it.
VACUUM can do that, mainly because it doesn't care if it visits some
entries twice (and even then, it has to add a lot of pushups to ensure
it doesn't miss any ent
2012/8/26 Tom Lane :
> Jeff Janes writes:
>> On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer wrote:
>>> Should the following setup qualify for an index scan?
>
>> ... Also, your filler is highly compressible, which means the table is
>> much smaller than you might think.
>
> Yeah. I see somethi
Jeff Janes writes:
> On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer wrote:
>> Should the following setup qualify for an index scan?
> ... Also, your filler is highly compressible, which means the table is
> much smaller than you might think.
Yeah. I see something like 100 rows per page with
On Sun, Aug 26, 2012 at 8:02 AM, Thomas Kellerer wrote:
> Tom Lane wrote on 26.08.2012 16:31:
>
>> Thomas Kellerer writes:
>>>
>>> I'm playing around with 9.2 beta4 and was looking into the new Index Only
>>> Scan feature.
>>> I was a bit surprised that a "count(*)" query does not use an index.
>
Tom Lane wrote on 26.08.2012 16:31:
Thomas Kellerer writes:
I'm playing around with 9.2 beta4 and was looking into the new Index Only Scan
feature.
I was a bit surprised that a "count(*)" query does not use an index.
Works for me. However, the cost estimate for that is heavily dependent
on
Thomas Kellerer writes:
> I'm playing around with 9.2 beta4 and was looking into the new Index Only
> Scan feature.
> I was a bit surprised that a "count(*)" query does not use an index.
Works for me. However, the cost estimate for that is heavily dependent
on how much of the table is known all
Hi,
I'm playing around with 9.2 beta4 and was looking into the new Index Only Scan
feature.
I was a bit surprised that a "count(*)" query does not use an index.
Not even a count(col) where col is the PK of the table.
Is that intended? If so, why is that the case?
I would have thought that this
18 matches
Mail list logo
