Re: index only scan question

2018-11-09 Thread Laurenz Albe
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

Re: index only scan question

2018-11-09 Thread Daniel Westermann
sorry, hit the wrong key >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

Re: index only scan question

2018-11-09 Thread Daniel Westermann
>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 “

Re: index only scan question

2018-11-09 Thread Daniel Westermann
>I'd say the old index tuple was killed during the first scan: >https://www.cybertec-postgresql.com/en/killed-index-tuples/ Thanks Laurenz, I will check that

Re: index only scan question

2018-11-09 Thread Daniel Westermann
>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);

Re: index only scan question

2018-11-09 Thread Andreas Kretschmer
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

Re: Full list of operations that constitute a "maintenance" operation?

2018-11-09 Thread Andrew Gierth
> "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 AD

Re: index only scan question

2018-11-09 Thread Laurenz Albe
Daniel Westermann wrote: > question: Given these steps: > > > postgres=# explain (analyze,buffers,costs off) select a from t1 where b = 5; > QUERY PLAN > -- > I

index only scan question

2018-11-09 Thread Daniel Westermann
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 t1

Re: Full list of operations that constitute a "maintenance" operation?

2018-11-09 Thread Laurenz Albe
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 m

Re: ERROR: found multixact from before relminmxid

2018-11-09 Thread Adrien NAYRAT
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 agai

Full list of operations that constitute a "maintenance" operation?

2018-11-09 Thread Lance Luvaul
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 my scripts... are they maintenan

FIXED: backend crash on DELETE, reproducible locally

2018-11-09 Thread Karsten Hilbert
For the record: Regarding backend crash when DELETEing tuples older than a recent ALTER TABLE ADD COLUMN: > > > On Fri, Nov 02, 2018 at 11:56:58PM -0400, Tom Lane wrote: > > >> I was feeling baffled about this, but it suddenly occurs to me that maybe > > >> the bug fixed in 040a1df61/372102b81 ex