On Wed, May 23, 2012 at 11:05 AM, Robert Haas wrote:
> On Wed, May 23, 2012 at 2:00 PM, Jeff Janes wrote:
>>
>> I'm running some tests where I mix the work load of pgbench by doing
>> "TPC-B (sort of)" transaction mixed in with a variable number of
>> SELECT-only transactions, at a ratio varying
On Tue, 2012-05-22 at 10:24 -0700, Jeff Janes wrote:
> Now that there are index only scans, there is a use case for having a
> composite index which has the primary key or a unique key as the
> prefix column(s) but with extra columns after that. Currently you
> would also need another index with e
On 23 May 2012 18:13, Robert Haas wrote:
> On Tue, May 22, 2012 at 5:26 PM, Simon Riggs wrote:
>>> A bigger problem is that creating such an index turns all
>>> of pgbench's write traffic from HOT updates into non-HOT updates,
>>> which means this is probably only going to be a win if the write
On Wed, May 23, 2012 at 2:00 PM, Jeff Janes wrote:
> On Tue, May 22, 2012 at 11:01 AM, Robert Haas wrote:
>> On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
>>> Jeff Janes writes:
Now that there are index only scans, there is a use case for having a
composite index which has the prim
On Tue, May 22, 2012 at 11:01 AM, Robert Haas wrote:
> On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
>> Jeff Janes writes:
>>> Now that there are index only scans, there is a use case for having a
>>> composite index which has the primary key or a unique key as the
>>> prefix column(s) but wi
Robert Haas writes:
> I don't object to the feature, but I think it's real-world utility
> will be more limited than we might hope. When covering indexes are
> not in play, someone might choose to index only, say, the primary key.
> And maybe the primary key doesn't change very often, so HOT st
On Tue, May 22, 2012 at 5:26 PM, Simon Riggs wrote:
>> A bigger problem is that creating such an index turns all
>> of pgbench's write traffic from HOT updates into non-HOT updates,
>> which means this is probably only going to be a win if the write
>> volume is miniscule.
>
> Not sure whether yo
On 22 May 2012 18:41, Tom Lane wrote:
> It'd be better to work on index-organized tables
My earlier analysis showed that IOTs are essentially the same thing as
block-level indexes, referred to as GITs by Heikki. (Robert referred
to these as Lossy Indexes recently, which was not the case - that
a
On 22 May 2012 19:01, Robert Haas wrote:
> On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
>> Jeff Janes writes:
>>> Now that there are index only scans, there is a use case for having a
>>> composite index which has the primary key or a unique key as the
>>> prefix column(s) but with extra col
On Tue, May 22, 2012 at 1:36 PM, Simon Riggs wrote:
> On 22 May 2012 18:24, Jeff Janes wrote:
> > Now that there are index only scans, there is a use case for having a
> > composite index which has the primary key or a unique key as the
> > prefix column(s) but with extra columns after that. Cu
On Tue, May 22, 2012 at 10:41 AM, Tom Lane wrote:
> Jeff Janes writes:
>> Now that there are index only scans, there is a use case for having a
>> composite index which has the primary key or a unique key as the
>> prefix column(s) but with extra columns after that. Currently you
>> would also n
On Tue, May 22, 2012 at 1:41 PM, Tom Lane wrote:
> Jeff Janes writes:
>> Now that there are index only scans, there is a use case for having a
>> composite index which has the primary key or a unique key as the
>> prefix column(s) but with extra columns after that. Currently you
>> would also ne
Jeff Janes writes:
> Now that there are index only scans, there is a use case for having a
> composite index which has the primary key or a unique key as the
> prefix column(s) but with extra columns after that. Currently you
> would also need another index with exactly the primary/unique key,
>
On 22 May 2012 18:24, Jeff Janes wrote:
> Now that there are index only scans, there is a use case for having a
> composite index which has the primary key or a unique key as the
> prefix column(s) but with extra columns after that. Currently you
> would also need another index with exactly the p
Now that there are index only scans, there is a use case for having a
composite index which has the primary key or a unique key as the
prefix column(s) but with extra columns after that. Currently you
would also need another index with exactly the primary/unique key,
which seems like a waste of st
15 matches
Mail list logo
