Re: Are my autovacuum settings too aggressive for this table?

On Fri, 2019-11-01 at 18:58 +, Jason Ralph wrote: > autovacuum_naptime = 1h > autovacuum_vacuum_threshold = 1 > autovacuum_analyze_threshold = 5000 > autovacuum_vacuum_scale_factor = 0.002 > autovacuum_analyze_scale_factor = 0.001 These seem to be crazy settings. Only once an hour you tes

Re: explain plan difference

Thanks very much for the explanation Tom !! You are correct - there are dropped columns in the original. Cheers, Steve On Mon, Nov 4, 2019 at 3:01 PM Tom Lane wrote: > Steve Baldwin writes: > > I guess the difference doesn't have a huge bearing (as far as I can tell) > > on the result, but i

Re: explain plan difference

Steve Baldwin writes: > I guess the difference doesn't have a huge bearing (as far as I can tell) > on the result, but it just seems odd that the inner-most 'Output' step > outputs the entire row in the case of the copy and only the required field > in the case of the original table. What triggers

explain plan difference

Can someone please help me understand this: b2bc_dev=# *vacuum full analyze invoice;* VACUUM Time: 39.671 ms b2bc_dev=# *create table invoice_copy as select * from invoice;* SELECT 23 Time: 11.557 ms b2bc_dev=# *alter table invoice_copy add primary key (id);* ALTER TABLE Time: 9.257 ms b2bc_dev=#

Re: select view definition from pg_views feature request

Michael Shapiro writes: > It seems that the definition of a view from pg_catalog.pg_views does not > qualify the tables used in the view if the tables are in the current search > path. > Is it possible to either have the definition always qualify all tables > independent of the search_path (or el

select view definition from pg_views feature request

It seems that the definition of a view from pg_catalog.pg_views does not qualify the tables used in the view if the tables are in the current search path. Is it possible to either have the definition always qualify all tables independent of the search_path (or else provide a new column that does t

Re: Getting following error in using cursor to fetch the records from a large table in c language(current transaction is aborted, commands ignored until end of transaction block)

M Tarkeshwar Rao: On Sat, Nov 2, 2019 at 5:16 PM M Tarkeshwar Rao wrote: > Thanks Yes it is in c++. Actually we just written this code. > Due to vaccum full cursor query failing on a connection and all the > subsequent queries are failing and we > found shared errors in /var/logs of the postgres