On Thu, Feb 09, 2012 at 12:02:29PM -0500, Robert Haas wrote:
> When Heikki worked up his original index-only scan patches (which
> didn't end up looking much like what eventually got committed), he had
> the notion of an index-only qual. That is, given a query like this:
>
> select sum(1) from fo
On Sat, Feb 11, 2012 at 7:16 AM, Jesper Krogh wrote:
> Ok, but there are still cases where we don't even need to construct
> a data tuple at all:
>
> 2012-02-11 13:14:01.579 jk=# explain select count(*) from testtable where
> fts @@ to_tsquery('english','test1');
> Q
On 2012-02-09 22:17, Jesper Krogh wrote:
On 2012-02-09 21:09, Robert Haas wrote:
That doesn't make sense to me. If you probe index A for rows where a
= 1 and find that CTID (100,1) is such a row, and now want to return a
column value b that is not present in that index, the fastest way to
get t
On 2012-02-09 21:09, Robert Haas wrote:
That doesn't make sense to me. If you probe index A for rows where a
= 1 and find that CTID (100,1) is such a row, and now want to return a
column value b that is not present in that index, the fastest way to
get the row is going to be to fetch block 100 f
On Thu, Feb 9, 2012 at 1:33 PM, Jesper Krogh wrote:
> On 2012-02-09 18:02, Robert Haas wrote:
>>
>> I don't have any appetite for trying to do anything more with
>> index-only scans for 9.2, though maybe someone else will think
>> otherwise. But I would like very much to get KaiGai's leakproof st
On 2012-02-09 18:02, Robert Haas wrote:
I don't have any appetite for trying to do anything more with
index-only scans for 9.2, though maybe someone else will think
otherwise. But I would like very much to get KaiGai's leakproof stuff
committed, and so it seems like a good idea to reconcile the
I added this URL to the existing TODO item.
---
Heikki Linnakangas wrote:
> Here is an updated version of my patch to return data from b-tree
> indexes, and use it to satisfy quals.
>
> I added a new column 'amregurgitate'
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Barring objections, I'm going to apply the indexam API changes part,
>> since that simplifies the code in question regardless of the rest of the
>> work. I'm pretty happy now with the indexfilter patch as well, but want
>> to do some more testing on
Heikki Linnakangas writes:
> Barring objections, I'm going to apply the indexam API changes part,
> since that simplifies the code in question regardless of the rest of the
> work. I'm pretty happy now with the indexfilter patch as well, but want
> to do some more testing on that before committing
On Fri, Aug 21, 2009 at 7:27 AM, Heikki
Linnakangas wrote:
> Greg Stark wrote:
>> It looks like right now if an indexam has amregurgitate
>> set but not amhasgettuple then weird things could happen.
>
> The combination (amregurgitate && !amhasgettuple) makes no sense, BTW.
> If an indexam has no ge
Greg Stark wrote:
> It looks like right now if an indexam has amregurgitate
> set but not amhasgettuple then weird things could happen.
The combination (amregurgitate && !amhasgettuple) makes no sense, BTW.
If an indexam has no gettuple function, there's no way it can return
data from the index.
Greg Stark wrote:
> On Fri, Aug 21, 2009 at 12:43 PM, Heikki
> Linnakangas wrote:
>> Here is an updated version of my patch to return data from b-tree
>> indexes, and use it to satisfy quals.
>
> + if (!found_clause && useful_pathkeys == NIL &&
> !useful_predicate)
> +
On Fri, Aug 21, 2009 at 12:43 PM, Heikki
Linnakangas wrote:
> Here is an updated version of my patch to return data from b-tree
> indexes, and use it to satisfy quals.
+ if (!found_clause && useful_pathkeys == NIL &&
!useful_predicate)
+ ipath->
On Fri, Aug 21, 2009 at 12:43 PM, Heikki
Linnakangas wrote:
>
> I added a new column 'amregurgitate' to pg_am, to mark which indexams
> can return index tuples.
Very picturesque but uh, perhaps the more mundane "amcanrettuples"
would be clearer?
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Se
14 matches
Mail list logo
