On 2018-02-28 13:15:45 +1300, David Rowley wrote:
> On 28 February 2018 at 11:11, Andres Freund wrote:
> > I'm fairly certain that only vacuum and table rewrites like cluster sets
> > all-visible,
>
> I don't think the pages are set all visible again after a rewrite.
You're right. We freeze the
On 28 February 2018 at 11:11, Andres Freund wrote:
> I'm fairly certain that only vacuum and table rewrites like cluster sets
> all-visible,
I don't think the pages are set all visible again after a rewrite.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development,
On 2018-02-27 16:58:11 -0500, Tom Lane wrote:
> > Also, I recall discussion that select statements will touch the visibility
> > map (hence causing write I/O even in a read-only query) but [1] indicates
> > that only vacuum will set them ddl will clear them.
>
> Hm, I don't recall that, but I've n
On Tue, Feb 27, 2018 at 2:58 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>
> > Also, I recall discussion that select statements will touch the
> visibility
> > map (hence causing write I/O even in a read-only query) but [1] indicates
> > that only vacuum will set them ddl will clear them
"David G. Johnston" writes:
> If one runs vacuum on a table (small or otherwise) that is currently
> choosing an index scan as its best plan how likely is it that post-vacuum
> an index-only plan would be chosen if the index type and column presence
> conditions are met?
Offhand I think it would
On Tue, Feb 27, 2018 at 2:08 PM, Tom Lane wrote:
> Hadi Moshayedi writes:
> > I am wondering why is it not using index-only-scan (which would use the
> > cache better) and instead it does a bitmap scan?
>
> Never experiment on an empty table and assume that the resulting plan
> is the same as yo
Hadi Moshayedi writes:
> I am wondering why is it not using index-only-scan (which would use the
> cache better) and instead it does a bitmap scan?
Never experiment on an empty table and assume that the resulting plan
is the same as you'd get on a large table.
In this case, not only don't you ha
With the following definition:
create table t1 (a int, b int, c int);
create index on t1 (a,b,c);
I get the following plan for the following query:
postgres=# explain select sum(c) from t1 where a > 0;
QUERY PLAN
--
With the following definition:
create table t1 (a int, b int, c int);
create index on t1 (a,b,c);
I get the following plan for the following query:
postgres=# explain select sum(c) from t1 where a > 0;
QUERY
PLAN
---
