On 2 February 2012 01:40, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 7:44 PM, Robert Haas wrote:
>> So, I guess the trade-off here is that, since sinval messages aren't
>> processed immediately, we often won't notice the VM extension until
>> the next statement starts, whereas with the current i
On Wed, Feb 1, 2012 at 7:44 PM, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 4:09 AM, Dean Rasheed wrote:
>>> The real objection to this probably is that if it only saves anything
>>> for tables that don't have a VM yet, it's dubious whether it's worth
>>> doing. But if we can avoid wasted checks
On Wed, Feb 1, 2012 at 4:09 AM, Dean Rasheed wrote:
>> The real objection to this probably is that if it only saves anything
>> for tables that don't have a VM yet, it's dubious whether it's worth
>> doing. But if we can avoid wasted checks for VM extension as well,
>> then I think it's probably
On 31 January 2012 23:04, Tom Lane wrote:
> Dean Rasheed writes:
>> The thing I'm unsure about is whether sending sinval
>> messages when the visibility map is extended is a good idea.
>
> Seems perfectly reasonable to me. They'd occur so seldom as to be
> more than repaid if we can scrape some
Dean Rasheed writes:
> The thing I'm unsure about is whether sending sinval
> messages when the visibility map is extended is a good idea.
Seems perfectly reasonable to me. They'd occur so seldom as to be
more than repaid if we can scrape some cost out of the mainline paths.
The real objection
On 31 January 2012 19:49, Robert Haas wrote:
> On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed
> wrote:
>> In the case when we're asked to clear a bit, it would first try to pin
>> the relevant page, which would go through vm_readbuf() with extend set
>> to true. Then vm_extend() would notice that
On Tue, Jan 31, 2012 at 2:15 PM, Dean Rasheed wrote:
> In the case when we're asked to clear a bit, it would first try to pin
> the relevant page, which would go through vm_readbuf() with extend set
> to true. Then vm_extend() would notice that the visibility map had
> already been extended, and i
On 31 January 2012 17:35, Robert Haas wrote:
> On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed
> wrote:
>> Given a freshly created table (not vacuumed), and a query that uses an
>> index-only scan, for example:
>>
>> CREATE TABLE foo(a int PRIMARY KEY);
>> INSERT INTO foo SELECT * FROM generate_se
On Sun, Jan 29, 2012 at 2:47 AM, Dean Rasheed wrote:
> Given a freshly created table (not vacuumed), and a query that uses an
> index-only scan, for example:
>
> CREATE TABLE foo(a int PRIMARY KEY);
> INSERT INTO foo SELECT * FROM generate_series(1,100);
> ANALYSE foo;
>
> EXPLAIN ANALYSE SELE
Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT INTO foo SELECT * FROM generate_series(1,100);
ANALYSE foo;
EXPLAIN ANALYSE SELECT count(*) FROM foo WHERE a <= 1;
10 matches
Mail list logo
