On Tue, Feb 16, 2016 at 6:04 PM, Tom Lane wrote:
> I wrote:
> > Chris Travers writes:
> >> Unless there is a sense that this is a bad idea I will submit a doc
> patch.
>
> > I was already working on it ... I think what we want is something along
> > this line in the "Building Indexes Concurrentl
I wrote:
> Chris Travers writes:
>> Unless there is a sense that this is a bad idea I will submit a doc patch.
> I was already working on it ... I think what we want is something along
> this line in the "Building Indexes Concurrently" section of the CREATE
> INDEX ref page:
After further perusa
Chris Travers writes:
> Unless there is a sense that this is a bad idea I will submit a doc patch.
I was already working on it ... I think what we want is something along
this line in the "Building Indexes Concurrently" section of the CREATE
INDEX ref page:
*** create_index.sgml.orig Tue Feb
Unless there is a sense that this is a bad idea I will submit a doc patch.
On Mon, Feb 15, 2016 at 8:22 PM, Chris Travers
wrote:
> Hi;
>
> Today I ran into a question from a client as to why an index was not
> used. The index had been freshly created and was on a relatively small
> table (16k l
Hi;
Today I ran into a question from a client as to why an index was not used.
The index had been freshly created and was on a relatively small table (16k
live rows, but 300k dead tuples). The resulting sequential scan was taking
half a second.
I found that even when setting enable_seqscan to of
