Daniel Westermann wrote:
> >I'd say the old index tuple was killed during the first scan:
> >https://www.cybertec-postgresql.com/en/killed-index-tuples/
>
> ... from your blog: "Whenever an index scan fetches a heap tuple only to find
> that it is dead
> (that the entire “HOT chain” of tuples is
>Am 09.11.2018 um 13:58 schrieb Daniel Westermann:
>> Is that because of some sort of caching?
>no, but vacuum updated the visibility map in the meantime.
No, it do not, double checked that with:
select pg_visibility_map('t1'::regclass, 0);
Am 09.11.2018 um 13:58 schrieb Daniel Westermann:
Is that because of some sort of caching?
no, but vacuum updated the visibility map in the meantime.
Regards, Andreas
--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com
> "Lance" == Lance Luvaul writes:
Lance> Hi all, I've read on the Postgres documentation for
Lance> 'maintenance_work_mem' that VACUUM, CREATE INDEX, and ALTER
Lance> TABLE ADD FOREIGN KEY are considered maintenance operations, but
Lance> are there others? For example I use ALTER TABLE
Daniel Westermann wrote:
> question: Given these steps:
>
>
> postgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;
> QUERY PLAN
> --
>
Hi quick
question: Given these steps:
postgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5;
QUERY PLAN
--
Index Only Scan using i2 on
Lance Luvaul wrote:
> Hi all, I've read on the Postgres documentation for 'maintenance_work_mem'
> that VACUUM, CREATE INDEX,
> and ALTER TABLE ADD FOREIGN KEY are considered maintenance operations, but
> are there others?
> For example I use ALTER TABLE ADD COLUMN and ALTER TABLE SET LOGGED in
On 11/7/18 1:21 PM, Alexandre Arruda wrote:
The best solution that I have found is kick all connections and execute
a select for update to /dev/null in the affected tables, i.e.:
psql -o /dev/null -c "select * from table for update" database
After this, the vacuum is executed w/o problems
