Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-ed data

Hi, On 2018-11-28 03:06:58 +0100, Petr Jelinek wrote: > On 28/11/2018 02:14, Andres Freund wrote: > > On 2018-11-28 02:04:18 +0100, Tomas Vondra wrote: > >> Pushed and backpatched to 9.4- (same as e9edc1ba). > > > > Backpatching seems on the more aggressive end of things for an > > optimization.

Re: "pg_ctl: the PID file ... is empty" at end of make check

Thomas Munro writes: > Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce > it, but I noticed exactly the same thing on longfin the other day: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-11-25%2005%3A39%3A04 > Anyone know what that's about? No :-(.

idle-in-transaction timeout error does not give a hint

idle-in-transaction timeout error closed the session. I think in this case the error message should give a hint something like other errors (for example ERRCODE_CRASH_SHUTDOWN or ERRCODE_T_R_SERIALIZATION_FAILURE) to ask users to reconnect. Attached patch does that. Best regards, -- Tatsuo Ishii S

Re: "pg_ctl: the PID file ... is empty" at end of make check

On Wed, Nov 28, 2018 at 4:10 PM Tom Lane wrote: > Thomas Munro writes: > > Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce > > it, but I noticed exactly the same thing on longfin the other day: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-11-25%

Re: vacuum and autovacuum - is it good to configure the threshold at TABLE LEVEL?

Thanks, amul. I have already gone through this. What I would like to understand is the performance impact on autovacuum launcher and worker process when autovacuum is running from configurations done by *ALTER TABLE autvac_test SET (autovacuum_vacuum_scale_factor = 0, autovacuum_vacuum_threshold =

Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS

Hello. At Wed, 28 Nov 2018 11:27:23 +0900, Tatsuro Yamada wrote in > Hi, > > On 2018/11/26 11:05, Tatsuro Yamada wrote: > I couldn't write patches details on previous email, so I write > more explanation for that on this email. > > > * tab_completion_alter_index_set_statistics.patch > =

Re: Planning time of Generic plan for a table partitioned into a lot

On Tue, 27 Nov 2018 at 23:05, Kato, Sho wrote: > I found that making a generic plan of SELECT/UPDATE/DELETE for a table > partitioned into thousands is slow. > Especially, UPDATE/DELETE statement is too slow. It's quite well known and also documented [1] that this is slow. The manual reads: "Cu

Re: "pg_ctl: the PID file ... is empty" at end of make check

Thomas Munro writes: > Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce > it, but I noticed exactly the same thing on longfin the other day: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-11-25%2005%3A39%3A04 I trawled the buildfarm logs and discover

Re: postgres_fdw: oddity in costing aggregate pushdown paths

(2018/11/27 21:55), Etsuro Fujita wrote: > While working on [1], I noticed that since we don't set the selectivity > and cost of the local_conds (i.e., fpinfo->local_conds_sel and > fpinfo->local_conds_cost) properly in add_foreign_grouping_paths and > foreign_grouping_ok, estimate_path_cost_size p

Re: Planning time of Generic plan for a table partitioned into a lot

Hi Kato-san, On 2018/11/27 19:05, Kato, Sho wrote: > Of course, in case of plan_cache_mode = force_custom_plan, it is not problem > because unnecessary paths are pruned by speeding up planning with partitions > patch[1]. > > However, if plan_cachemode is force_generic_plan, generic plan is made

Re: vacuum and autovacuum - is it good to configure the threshold at TABLE LEVEL?

On Wed, Nov 28, 2018 at 9:11 AM rajan wrote: > > Thanks, amul. I have already gone through this. What I would like to > understand is the performance impact on autovacuum launcher and worker > process when autovacuum is running from configurations done by > *ALTER TABLE autvac_test SET (autovacuum

RE: Copy data to DSA area

Hi >From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com] >Sent: Wednesday, November 14, 2018 9:50 AM >To: Ideriha, Takeshi/出利葉 健 > >On Tue, Nov 13, 2018 at 10:59 PM Ideriha, Takeshi > >wrote: >> Can I check my understanding? >> The situation you are talking about is the following: >> Data s

Re: "pg_ctl: the PID file ... is empty" at end of make check

On Wed, Nov 28, 2018 at 5:28 PM Tom Lane wrote: > Thomas Munro writes: > > Today I saw a one-off case of $SUBJECT, on macOS. I can't reproduce > > it, but I noticed exactly the same thing on longfin the other day: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=longfin&dt=2018-11-25%

Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS

On 2018/11/28 13:14, Kyotaro HORIGUCHI wrote: Hello. At Wed, 28 Nov 2018 11:27:23 +0900, Tatsuro Yamada wrote in Hi, On 2018/11/26 11:05, Tatsuro Yamada wrote: I couldn't write patches details on previous email, so I write more explanation for that on this email. * tab_completion_alter_in

Re: "pg_ctl: the PID file ... is empty" at end of make check

Thomas Munro writes: > On Wed, Nov 28, 2018 at 5:28 PM Tom Lane wrote: >> So my theory is we broke something in HEAD a couple weeks ago. But what? > Hmm. Not seeing it. I'm trying to do it again, with a make check loop. >> The fsync changes you made are suspiciously close to this issue (ie o

Re: Planning time of Generic plan for a table partitioned into a lot

On 2018/11/28 13:46, Amit Langote wrote: > It's cheaper than using a cached generic plan (without re-planning), > because the latter has to pay the cost of AcquireExecutorLocks which takes > longer as the number of partitions increases. Perhaps something to try > fix fixing too. Not planning shou

Re: Minor typo

This is a noise from a Japanese having poor English skill.. At Wed, 28 Nov 2018 10:01:36 +0900, Michael Paquier wrote in <20181128010136.gu1...@paquier.xyz> > On Tue, Nov 27, 2018 at 07:51:03PM -0500, Stephen Frost wrote: > > That isn't at all what I got from that. > > > > A rewrite of this rea

Unnecessary asterisk in comment in postgres_fdw.c

Here is a small patch for removing $SUBJECT. Best regards, Etsuro Fujita diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c index a5830bb..d22c974 100644 --- a/contrib/postgres_fdw/postgres_fdw.c +++ b/contrib/postgres_fdw/postgres_fdw.c @@ -2887,7 +2887,7 @@ es

psql --csv and other parameters

I don't know if this really is a bug but it seems wrong to me: psql -A --csv -Xc "select * from pg_namespace order by 1" gives a difference result than psql --csv -A -Xc "select * from pg_namespace order by 1" I would say both should give the same result, and that result should be the same as

RE: idle-in-transaction timeout error does not give a hint

>From: Tatsuo Ishii [mailto:is...@sraoss.co.jp] >Sent: Wednesday, November 28, 2018 12:18 PM >To: pgsql-hackers@lists.postgresql.org >Subject: idle-in-transaction timeout error does not give a hint > >idle-in-transaction timeout error closed the session. I think in this case the >error >message sh

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Mon, Nov 26, 2018 at 5:40 PM Vik Fearing wrote: > > On 23/11/2018 00:09, Haribabu Kommi wrote: > > > > On Fri, Nov 23, 2018 at 1:54 AM Peter Eisentraut > > > > wrote: > > > > On 19/11/2018 06:18, Haribabu Kommi wrote: > > > Amit suggested anothe

<    1   2