On Wed, May 23, 2012 at 11:05 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 23, 2012 at 2:00 PM, Jeff Janes jeff.ja...@gmail.com 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
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
On Tue, May 22, 2012 at 5:26 PM, Simon Riggs si...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, May 22, 2012 at 11:01 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 22, 2012 at 1:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Now that there are index only scans, there is a use case for having a
composite index which has the primary key
On Wed, May 23, 2012 at 2:00 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, May 22, 2012 at 11:01 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 22, 2012 at 1:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Now that there are index only scans,
On 23 May 2012 18:13, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 22, 2012 at 5:26 PM, Simon Riggs si...@2ndquadrant.com 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
On 22 May 2012 18:24, Jeff Janes jeff.ja...@gmail.com 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
Jeff Janes jeff.ja...@gmail.com 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
On Tue, May 22, 2012 at 1:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com 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.
On Tue, May 22, 2012 at 10:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com 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
On Tue, May 22, 2012 at 1:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 22 May 2012 18:24, Jeff Janes jeff.ja...@gmail.com 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
On 22 May 2012 19:01, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 22, 2012 at 1:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com 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
On 22 May 2012 18:41, Tom Lane t...@sss.pgh.pa.us 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
14 matches
Mail list logo