Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

On Thu, Nov 16, 2017 at 2:43 PM, Peter Geoghegan <p...@bowt.ie> wrote: > On Thu, Nov 16, 2017 at 2:16 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > The only reference to super-exclusive lock in > src/backend/access/gin/README, > > that I can find, is about po

Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

On Thu, Nov 16, 2017 at 12:29 PM, Robert Haas wrote: > On Thu, Nov 16, 2017 at 7:08 AM, Masahiko Sawada > wrote: > > Agreed, that's better. Attached updated patch. > > Also I've added this to the next CF so as not to forget. > > Committed and

Re: Top-N sorts verses parallelism

On Tue, Dec 12, 2017 at 10:46 PM, Thomas Munro < thomas.mu...@enterprisedb.com> wrote: > Hi hackers, > > The start-up cost of bounded (top-N) sorts is sensitive at the small > end of N, and the > comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't > seem to correspond to reality.

Re: Top-N sorts verses parallelism

On Thu, Dec 14, 2017 at 5:12 PM, Thomas Munro wrote: > > > > This looks like a costing bug. The estimated cost of sorting 416,667 > > estimated tuples in one parallel worker is almost identical to the > estimated > > cost of sorting 1,000,000 tuples when

Re: Top-N sorts verses parallelism

On Tue, Dec 12, 2017 at 10:46 PM, Thomas Munro < thomas.mu...@enterprisedb.com> wrote: > Hi hackers, > > The start-up cost of bounded (top-N) sorts is sensitive at the small > end of N, and the > comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't > seem to correspond to reality.

Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

On Mon, Nov 13, 2017 at 8:08 PM, Peter Geoghegan wrote: > On Mon, Nov 13, 2017 at 6:56 PM, Masahiko Sawada > wrote: > >/* > > * We would like to prevent concurrent cleanup process. For that we > will > > * lock metapage in exclusive mode using

bgwriter_lru_maxpages range in postgresql.conf

(My earlier post has been stuck in infinite moderation due to the use of a common 6 letter abbreviation for configuration, so I will try again without it) With v10, commit 14ca9abfbe4643408a, the upper limit on bgwriter_lru_maxpages was changed from 1000 to INT_MAX / 2, but the

Re: bgwriter_lru_maxpages range in postgresql.conf

On Thu, Nov 16, 2017 at 11:10 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Nov 16, 2017 at 1:26 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > (My earlier post has been stuck in infinite moderation due to the use of > a > > common 6 letter abbrev

Re: pg_dumpall -r -c try to drop user postgres

On Tue, Dec 5, 2017 at 9:03 AM, Pavel Stehule wrote: > On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule >> wrote: >> > I am not sure if user postgres should be removed, so it is probably bug >> > >> > pg_dumpall -r -c | grep postgres >> > >> > DROP

Re: [HACKERS] postgres_fdw super user checks

On Tue, Dec 5, 2017 at 8:35 AM, Robert Haas wrote: > On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat > wrote: > > I think the real behaviour can be described as something like this: > > > > "Only superusers may connect to foreign servers

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 10:49 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 4 October 2017 at 18:13, Jeff Janes <jeff.ja...@gmail.com> wrote: > > > OK. And if you want the first one, you can wrap it in a view currently, > but > > if it were changed I do

Re: [HACKERS] postgres_fdw super user checks

On Thu, Oct 5, 2017 at 10:16 AM, Nico Williams <n...@cryptonector.com> wrote: > On Thu, Sep 14, 2017 at 04:08:08PM -0400, Robert Haas wrote: > > On Thu, Sep 14, 2017 at 2:33 PM, Jeff Janes <jeff.ja...@gmail.com> > wrote: > > > I think that foreign tables o

Re: Bitmap table scan cost per page formula

On Tue, Dec 19, 2017 at 11:55 AM, Haisheng Yuan wrote: > Hi hackers, > > This is Haisheng Yuan from Greenplum Database. > > We had some query in production showing that planner favors seqscan over > bitmapscan, and the execution of seqscan is 5x slower than using > bitmapscan,

Re: Bitmap table scan cost per page formula

On Wed, Dec 20, 2017 at 5:03 PM, Tom Lane wrote: > > The parabola is probably wrong in detail --- its behavior as we approach > reading all of the pages ought to be more asymptotic, seems like. > I suppose that the reason it appears to go below the seqscan cost at the > right

Re: Bitmap table scan cost per page formula

On Tue, Dec 19, 2017 at 7:25 PM, Justin Pryzby wrote: > > I started playing with this weeks ago (probably during Vitaliy's problem > report). Is there any reason cost_bitmap_heap_scan shouldn't interpolate > based > on correlation from seq_page_cost to rand_page_cost, same

Re: High CPU load caused by the autovacuum launcher process

On Fri, Jun 8, 2018 at 3:24 AM, Owayss Kabtoul wrote: > Hi folks, > > I ran into an issue where, on Postgres instances that have a very large > number of databases per cluster (~15K), the autovacuum process seems to > have a very high impact on CPU usage. Specifically, it is the autovacuum >

ALTER CONSTRAINT change action

Currently you can't change the ON DELETE action or ON UPDATE action of an existing constraint. You have to drop the constraint and create it again with the action you want. This is not a light-weight activity, as it has to validate the new constraint. Is there a fundamental reason that ALTER

Re: why partition pruning doesn't work?

On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane wrote: > > I agree though that it seems strange to special-case SQLValueFunction > rather than any-stable-expression. As long as the evaluation happens > at executor start (i.e. with the query's run-time snapshot) it should > be reasonable to simplify

Make deparsing of column defaults faster

The user docs say about column defaults: "The value is any variable-free expression (subqueries and cross-references to other columns in the current table are not allowed)" And also say about pg_get_expr "If the expression might contain Vars, specify the OID of the relation they refer to as the

Re: Scariest patch tournament, PostgreSQL 11 edition

On Mon, Jun 25, 2018 at 6:52 PM, Alvaro Herrera wrote: > Hackers, > > One month of beta testing has flown by, and enough bugs have already > been reported that your view of what patches are scariest might have > matured. You still have a few days before we close the contest at the > end of the

Re: Deadlock in multiple CIC.

On Wed, Dec 27, 2017 at 8:50 AM, Jeremy Finzel wrote: > I was able to get this compiled, and ran the test before on stock 9.6.6, > then on this patched version. I indeed reproduced it on 9.6.6, but on the > patched version, it indeed fixes my issue. > > Let me know if I can

Re: Speeding up pg_upgrade

On Thu, Dec 7, 2017 at 11:28 AM, Justin Pryzby wrote: > On Tue, Dec 05, 2017 at 09:01:35AM -0500, Bruce Momjian wrote: > > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about > > zero-downtime upgrades. ... we discussed speeding up pg_upgrade. > > > >

Re: [HACKERS] Removing useless DISTINCT clauses

On Mon, Nov 6, 2017 at 1:16 AM, David Rowley wrote: > In [1] we made a change to process the GROUP BY clause to remove any > group by items that are functionally dependent on some other GROUP BY > items. > > This really just checks if a table's PK columns are

Re: Possible performance regression with pg_dump of a large number of relations

On Thu, Jan 11, 2018 at 5:26 PM, Luke Cowell wrote: > I've been troubleshooting an issue with slow pg_dump times on postgres > 9.6.6. I believe something changed between 9.5.10 and 9.6.6 that has made > dumps significantly slower for databases with a large number of relations.

Deadlock in multiple CIC.

c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at least not as reliably as before) by dropping its own snapshot before waiting for all the other ones to go away. With commit 8aa3e47510b969354ea02a, concurrent CREATE INDEX CONCURRENTLY on different tables in the same database

Re: Deadlock in multiple CIC.

On Tue, Dec 26, 2017 at 8:31 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Jeff Janes wrote: > > c3d09b3bd23f5f6 fixed it so concurrent CIC would not deadlock (or at > least > > not as reliably as before) by dropping its own snapshot before waiting > for > &

Re: Why standby restores some WALs many times from archive?

On Thu, Dec 28, 2017 at 7:02 AM, Victor Yagofarov wrote: > Hi, > > I tried to ask a question in pgsql-general@ but got no response. > > I have postgres 9.4 standby with archive-based replication (via > restore_command). > Can you show us both your archive_command and your

Re: AS OF queries

On Thu, Dec 21, 2017 at 6:00 AM, Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > There is still one significant difference of my prototype implementation > with SQL standard: it associates timestamp with select statement, not with > particular table. > It seems to be more difficult to

MCV lists for highly skewed distributions

I want to revive a patch I sent couple years ago to the performance list, as I have seen the issue pop up repeatedly since then. Original thread is here: https://www.postgresql.org/message-id/CAK_s-G2tc8r0N3AqPr8fW5QsRQMbZNurgAQ%3D_ME1aaf4vOmnnA%40mail.gmail.com The problem is that if you have

Re: Bitmap table scan cost per page formula

On Wed, Dec 20, 2017 at 12:29 PM, Robert Haas wrote: > On Tue, Dec 19, 2017 at 2:55 PM, Haisheng Yuan wrote: >> >> Below is the graph (credit to Heikki) that plots the total estimated cost >> of a bitmap heap scan, where table size is 1 pages, and >>

Re: Bitmap table scan cost per page formula

On Wed, Dec 20, 2017 at 2:18 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Dec 20, 2017 at 4:20 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> >> It is not obvious to me that the parabola is wrong. I've certainly seen >> cases where readi

Re: TODO list (was Re: Contributing with code)

On Tue, Jan 2, 2018 at 2:48 PM, Robert Haas wrote: > On Sun, Dec 31, 2017 at 2:02 PM, David G. Johnston > wrote: > > It probably needs three sub-sections. Fist the raw ideas put forth by > > people not capable of implementation but needing

Re: Make deparsing of column defaults faster

On Mon, Jul 30, 2018 at 7:03 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 07/07/2018 20:07, Jeff Janes wrote: > > One case that your patch doesn't improve (neither does my posted one) is > > check constraints. To fix that, pg_get_constraintdef_worke

Re: add verbosity to pg_basebackup for sync

On Fri, Jul 27, 2018 at 7:10 PM, Michael Paquier wrote: > On Fri, Jul 27, 2018 at 11:58:42AM -0400, Jeff Janes wrote: > > But it was really waiting for the syncs of the new -D dir to finish. The > > attached patch adds a -v notice that it is starting to do the sync, with > &

Re: [PATCH] Improve geometric types

On Sat, Jul 28, 2018 at 9:54 PM, Tomas Vondra wrote: > > > I've committed the first two parts, after a review and testing. > > I'm getting a compiler warning now: geo_ops.c: In function 'line_closept_point': geo_ops.c:2528:7: warning: variable 'retval' set but not used

add verbosity to pg_basebackup for sync

On some recent testing, pg_basebackup -Fp was taking an annoying amount of time to finish once the it was done copying the data. Using -v seemed to blame this on "waiting for background process to finish streaming", based on that being the last message on display while the delay was happening.

Re: Deprecating, and scheduling removal of, pg_dump's tar format.

On Fri, Jul 27, 2018 at 12:51 PM, Robert Haas wrote: > On Thu, Jul 26, 2018 at 11:46 PM, Tom Lane wrote: > > Andres Freund writes: > >> Is there any real reason to retain it? > > > > As I recall, the principal argument for having it to begin with was > > that it's a "non proprietary" format

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

On Fri, Jul 20, 2018 at 5:56 PM, Marko Tiikkaja wrote: > On Fri, Jul 20, 2018 at 2:17 AM, Jeremy Schneider > wrote: > >> I'd like to bump this old bug that Lloyd filed for more discussion. It >> seems serious enough to me that we should at least talk about it. >> >> Anyone with simply the login

Re: Have an encrypted pgpass file

On Wed, Jul 18, 2018 at 5:52 PM, Tom Lane wrote: > Thomas Munro writes: > > On Thu, Jul 19, 2018 at 5:46 AM, Marco van Eck > wrote: > >> Since .pgpass files contain plain-text passwords, I searched for an > >> alternative. > >> In the attached patch I've added the possibility to run a command

Re: Invisible Indexes

On Mon, Jun 18, 2018 at 5:57 PM, Tom Lane wrote: > > I'm not sure about the "enforce constraint only" argument --- that > sounds like a made-up use-case to me. It's pretty hard to imagine > a case where a unique index applies to a query and yet you don't want > to use it. > I've not seen it

Re: Make deparsing of column defaults faster

On Thu, Jul 5, 2018 at 10:45 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 29.06.18 05:15, Jeff Janes wrote: > > Since pg_dump calls pg_get_expr once over and over again on the same > > table consecutively, perhaps we could cache the column alias assign

Re: How to use public key file to encrypt data

On Tue, Jul 3, 2018 at 6:17 AM, ROS Didier wrote: > Hi > >I Would like to know how to encrypt data with *physical* > public key files. I can’t find any documentation about this subject. > >Thanks in advance > This isn't really a suitable question for

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

On Sun, Mar 4, 2018 at 3:18 PM, David Gould <da...@sonic.net> wrote: > On Sun, 4 Mar 2018 07:49:46 -0800 > Jeff Janes <jeff.ja...@gmail.com> wrote: > > > On Wed, Jan 17, 2018 at 4:49 PM, David Gould <da...@sonic.net> wrote: > ... > > > > Maybe a

WARNING in parallel index creation.

If i run: pgbench -i -s30 And then create the function: CREATE OR REPLACE FUNCTION foobar(text) RETURNS text LANGUAGE plperl IMMUTABLE PARALLEL SAFE STRICT COST 1 AS $function$ return scalar reverse($_[0]); $function$; Then when I create in index, I get a warning: jjanes=# create

neqjoinsel versus "refresh materialized view concurrently"

The following commit has caused a devastating performance regression in concurrent refresh of MV: commit 7ca25b7de6aefa5537e0dbe56541bc41c0464f97 Author: Tom Lane Date: Wed Nov 29 22:00:29 2017 -0500 Fix neqjoinsel's behavior for semi/anti join cases. The below

Re: INOUT parameters in procedures

On Thu, Mar 15, 2018 at 6:58 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: > > I'm getting compiler warnings: > > pl_exec.c: In function 'exec_stmt_call': > > pl_exec.c:2089:8: warning: variable 'numarg

Re: INOUT parameters in procedures

On Wed, Mar 14, 2018 at 10:46 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > committed > > I'm getting compiler warnings: pl_exec.c: In function 'exec_stmt_call': pl_exec.c:2089:8: warning: variable 'numargs' set but not used [-Wunused-but-set-variable] int numargs;

Re: neqjoinsel versus "refresh materialized view concurrently"

On Tue, Mar 13, 2018 at 4:57 PM, Thomas Munro wrote: > On Wed, Mar 14, 2018 at 12:29 PM, Tom Lane wrote: > > Thomas Munro writes: > >> There is a fundamental and complicated estimation problem lurking here > >>

Re: Ambigous Plan - Larger Table on Hash Side

On Tue, Mar 13, 2018 at 4:02 AM, Narendra Pradeep U U < narendra.prad...@zohocorp.com> wrote: > Hi, > Thanks everyone for your suggestions. I would like to add explain > analyze of both the plans so that we can have broader picture. > > I have a work_mem of 1000 MB. > Is it possible to

Re: WIP: Covering + unique indexes.

On Sat, Apr 7, 2018 at 4:02 PM, Teodor Sigaev wrote: > Thanks to everyone, pushed. > > Indeed thanks, this will be a nice feature. It is giving me a compiler warning on non-cassert builds using gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609: indextuple.c: In function

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

On Wed, Jan 17, 2018 at 4:49 PM, David Gould wrote: > > Please add the attached patch and this discussion to the open commit fest. > The > original bugs thread is here: 2018011254.1408.8342@wrigl > eys.postgresql.org. > > Bug reference: 15005 > Logged by: David

Re: Make deparsing of column defaults faster

On Mon, Jun 4, 2018 at 10:00 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 6/4/18 20:55, Jeff Janes wrote: > > The user docs say about column defaults: "The value is any variable-free > > expression (subqueries and cross-references to other column

Re: WAL archive (archive_mode = always) ?

On Fri, Oct 19, 2018 at 10:00 AM Adelino Silva < adelino.j.si...@googlemail.com> wrote: > Hi, > > What is the advantage to use archive_mode = always in a slave server > compared to archive_mode = on (shared WAL archive) ? > I only see duplication of Wal files, what is the purpose of this feature

Re: WAL archive (archive_mode = always) ?

On Mon, Oct 22, 2018 at 5:06 AM Adelino Silva < adelino.j.si...@googlemail.com> wrote: > Hello Takayuki, > > Sorry can you explain how we can same network bandwidth by not sending the > WAL archive from the primary to the standby(s). > I possible scenario is have to multiple standby servers in

Re: Estimating number of distinct values.

On Wed, Oct 24, 2018 at 10:07 AM Konstantin Knizhnik < k.knizh...@postgrespro.ru> wrote: > > Real number of distinct value for this dataset is about 10 millions. For > some reasons, sampling using random blocks and Vitter algorithm produces > worser results than just examining first 3 rows of

Re: Buildfarm failures for hash indexes: buffer leaks

On Tue, Oct 23, 2018 at 10:51 AM Andres Freund wrote: > On 2018-10-23 13:54:31 +0200, Fabien COELHO wrote: > > > > Hello Tom & Amit, > > > > > > > Both animals use gcc experimental versions, which may rather > underline a > > > > > new bug in gcc head rather than an existing issue in pg. Or not.

Make relcache init write errors not be fatal

After running a testing server out of storage, I tried to track down why it was so hard to get it back up again. (Rather than what I usually do which is just throwing it away and making the test be smaller). I couldn't start a backend because it couldn't write the relcache init file. I found

Re: Make relcache init write errors not be fatal

On Sat, Dec 22, 2018 at 8:54 PM Andres Freund wrote: > Hi, > > On 2018-12-22 20:49:58 -0500, Jeff Janes wrote: > > After running a testing server out of storage, I tried to track down why > it > > was so hard to get it back up again. (Rather than what I usually do >

Don't wake up to check trigger file if none is configured

A streaming replica waiting on WAL from the master will wake up every 5 seconds to check for a trigger file. This is pointless if no trigger file has been configured. The attached patch suppresses the timeout when there is no trigger file configured. A minor thing to be sure, but there was a

Re: Don't wake up to check trigger file if none is configured

On Sat, Nov 24, 2018 at 11:29 AM Jeff Janes wrote: > A streaming replica waiting on WAL from the master will wake up every 5 > seconds to check for a trigger file. This is pointless if no trigger file > has been configured. > > The attached patch suppresses the timeout when ther

compiler warning in pgcrypto imath.c

When compiling on an AWS 64 bit Arm machine, I get this compiler warning: imath.c: In function 's_ksqr': imath.c:2590:6: warning: variable 'carry' set but not used [-Wunused-but-set-variable] carry; ^ With this version(): PostgreSQL 12devel on aarch64-unknown-linux-gnu, compiled

Re: pg_upgrade: Pass -j down to vacuumdb

On Fri, Mar 29, 2019 at 5:58 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-28 02:43, Jeff Janes wrote: > > At first blush I thought it was obvious that you would not want to run > > analyze-in-stages in parallel. But after thinki

Re: pg_upgrade: Pass -j down to vacuumdb

On Tue, Mar 26, 2019 at 7:28 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-25 22:57, Tom Lane wrote: > > + fprintf(script, "echo %sYou may wish to add --jobs=N for parallel > analyzing.%s\n", > > + ECHO_QUOTE, ECHO_QUOTE); > > But then you get

Re: [HACKERS] generated columns

On Sat, Mar 30, 2019 at 4:03 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-03-26 20:50, Pavel Stehule wrote: > > It is great feature and I'll mark this feature as ready for commit > > Committed, thanks. > I can't do a same-major-version pg_upgrade across this commit,

Re: Bloom index cost model seems to be wrong

I've moved this to the hackers list, and added Teodor and Alexander of the bloom extension, as I would like to hear their opinions on the costing. On Tue, Feb 12, 2019 at 4:17 PM Tom Lane wrote: > > It's possible that a good cost model for bloom is so far outside > genericcostestimate's ideas

Re: Bloom index cost model seems to be wrong

On Sun, Feb 24, 2019 at 11:09 AM Jeff Janes wrote: > I've moved this to the hackers list, and added Teodor and Alexander of the > bloom extension, as I would like to hear their opinions on the costing. > My previous patch had accidentally included a couple lines of a differen

Re: Index Skip Scan

On Thu, Jan 31, 2019 at 1:32 AM Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello. > > At Wed, 30 Jan 2019 18:19:05 +0100, Dmitry Dolgov <9erthali...@gmail.com> > wrote in aa+fz3guncutf52q1sufb7ise37tjpsd...@mail.gmail.com> > > A bit of adjustment after nodes/relation ->

Re: Index Skip Scan

On Wed, Feb 20, 2019 at 11:33 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Fri, Feb 1, 2019 at 8:24 PM Jesper Pedersen < > jesper.peder...@redhat.com> wrote: > > > > Dmitry and I will look at this and take it into account for the next > > version. > > In the meantime, just to not

Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits

On Thu, Feb 21, 2019 at 1:05 AM Pavan Deolasee wrote: > Hi, > > Jeff Janes raised an issue [1] about PD_ALL_VISIBLE not being set > correctly while loading data via COPY FREEZE and had also posted a draft > patch. > > I now have what I think is a more complete pat

Re: Problems with plan estimates in postgres_fdw

On Wed, Jan 30, 2019 at 6:12 AM Etsuro Fujita wrote: > (2018/12/28 15:50), Etsuro Fujita wrote: > > Attached is a new version of the > > patch. > > Here is an updated version of the patch set. Changes are: > > * In the previous version, LIMIT without OFFSET was not performed > remotely as the

Re: jsonpath

On Sat, Mar 16, 2019 at 5:36 AM Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > So, pushed. Many thanks to reviewers and authors! > I think these files have to be cleaned up by "make maintainer-clean" ./src/backend/utils/adt/jsonpath_gram.c ./src/backend/utils/adt/jsonpath_scan.c

Re: Should we increase the default vacuum_cost_limit?

On Wed, Mar 6, 2019 at 2:54 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > On 3/6/19 1:38 PM, Jeremy Schneider wrote: > > On 3/5/19 14:14, Andrew Dunstan wrote: > >> This patch is tiny, seems perfectly reasonable, and has plenty of > >> support. I'm going to commit it shortly

Hash index initial size is too large given NULLs or partial indexes

Referring to this thread: https://dba.stackexchange.com/questions/231647/why-are-partial-postgresql-hash-indices-not-smaller-than-full-indices When a hash index is created on a populated table, it estimates the number of buckets to start out with based on the number of tuples returned by

Re: GiST VACUUM

On Tue, Mar 5, 2019 at 8:21 AM Heikki Linnakangas wrote: > On 05/03/2019 02:26, Andrey Borodin wrote: > >> I also tried your amcheck tool with this. It did not report any > >> errors. > >> > >> Attached is also latest version of the patch itself. It is the > >> same as your latest patch v19,

Re: TupleTableSlot abstraction

On Fri, Nov 16, 2018 at 7:46 PM Andres Freund wrote: > Hi, > > On 2018-11-13 15:30:21 -0800, Andres Freund wrote: > > What I'm now planning to do is to go through the big comment in > > tuptable.h and update that to the new world. While I'm not convinced > > that that that's the best place for

Re: Actual Cost

On Sat, Feb 16, 2019 at 10:33 PM Donald Dong wrote: > On Feb 16, 2019, at 6:44 PM, Tomas Vondra wrote: > > > > On 2/17/19 3:40 AM, David Fetter wrote: > >> > >> As someone not volunteering to do any of the work, I think it'd be a > >> nice thing to have. How large an effort would you guess it

Re: Should the docs have a warning about pg_stat_reset()?

On Wed, Apr 10, 2019 at 2:52 PM Bruce Momjian wrote: > > OK, let me step back. Why are people resetting the statistics > regularly? Based on that purpose, does it make sense to clear the > stats that effect autovacuum? > When I've done it (not regularly, thankfully), it was usually because I

improve transparency of bitmap-only heap scans

When bitmap-only heap scans were introduced in v11 (7c70996ebf0949b142a99) no changes were made to "EXPLAIN". This makes the feature rather opaque. You can sometimes figure out what is going by the output of EXPLAIN (ANALYZE, BUFFERS), but that is unintuitive and fragile. Looking at the

crash testing suggestions for 12 beta 1

Now that beta is out, I wanted to do some crash-recovery testing where I inject PANIC-inducing faults and see if it recovers correctly. A long-lived Perl process keeps track of what it should find after the crash, and verifies that it finds it. You will probably be familiar with the general theme

pg_upgrade --clone error checking

With the new pg_upgrade --clone, if we are going to end up throwing the error "file cloning not supported on this platform" (which seems to depend only on ifdefs) I think we should throw it first thing, before any other checks are done and certainly before pg_dump gets run. This might result in

Re: compiler warning in pgcrypto imath.c

On Sat, May 4, 2019 at 3:15 AM Noah Misch wrote: > > I pushed Jeff's patch. > Thank you. I've re-tested it and I get warning-free compilation now. Cheers, Jeff

make maintainer-clean and config.cache

In side-note in another thread Tom pointed out the speed improvements of using an autoconf cache when re-building, which sounded nice to me as config takes an annoyingly long time and is not parallelized. But the config.cache files gets deleted by make maintainer-clean. Doesn't that mostly

Re: Usage of epoch in txid_current

On Sat, May 4, 2019 at 1:34 PM Jeff Janes wrote: > On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro > wrote: > >> On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas >> wrote: >> > Once we have the FullTransactionId type and basic macros in place, I'm >> >

Re: Usage of epoch in txid_current

On Thu, Mar 28, 2019 at 1:30 AM Thomas Munro wrote: > On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas > wrote: > > Once we have the FullTransactionId type and basic macros in place, I'm > > sure we could tidy up a bunch of code by using them. Thanks for the reviews! Pushed. > I think

Re: pg_upgrade --clone error checking

On Thu, May 2, 2019 at 12:28 PM Alvaro Herrera wrote: > On 2019-May-02, Jeff Janes wrote: > > > > > When something is doomed to fail, we should report the failure as early > as > > feasibly detectable. > > I agree -- this check should be done before checking the

Re: pg_upgrade --clone error checking

On Thu, May 2, 2019 at 11:57 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-05-01 22:10, Jeff Janes wrote: > > With the new pg_upgrade --clone, if we are going to end up throwing the > > error "file cloning not supported on this platform"

Re: pg_upgrade --clone error checking

On Fri, May 3, 2019 at 3:53 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2019-05-02 20:03, Jeff Janes wrote: > > It looks like it was designed for early checking, it just wasn't placed > > early enough. So changing it is pretty easy, as check_file_cl

mcv compiler warning

One of the recent mcv commits introduced an unused variable warning. mcv.c: In function 'statext_mcv_serialize': mcv.c:914:7: warning: unused variable 'itemlen' [-Wunused-variable] int itemlen = ITEM_SIZE(dim); The attached fixes it. Cheers, Jeff mcv_assert_warning.patch Description:

Re: TRACE_SORT defined by default

On Wed, Apr 24, 2019 at 6:04 PM Tom Lane wrote: > Peter Geoghegan writes: > > > In > > any case the current status quo is that it's built by default. I have > > used it in production, though not very often. It's easy to turn it on > > and off. > > Would any non-wizard really have a use for it?

Re: Can't we give better table bloat stats easily?

On Fri, Aug 16, 2019 at 8:39 PM Greg Stark wrote: > Everywhere I've worked I've seen people struggle with table bloat. It's > hard to even measure how much of it you have or where, let alone actually > fix it. > > If you search online you'll find dozens of different queries estimating > how much

Default JIT setting in V12

Since JIT is on by default in v12, I wanted to revisit the issue raised in https://www.postgresql.org/message-id/CAMkU=1zVhQ5k5d=YyHNyrigLUNTkOj4=YB17s9--3ts8H-SO=q...@mail.gmail.com When the total estimated cost is between jit_above_cost and jit_optimize_above_cost, I get a substantial

Re: Default JIT setting in V12

On Wed, Sep 4, 2019 at 11:24 AM Andres Freund wrote: > Hi, > > On 2019-09-04 07:51:16 -0700, Andres Freund wrote: > > Or better, something slightly more complete, like the attached (which > affects both code-gen time optimizations (which are more like peephole > ones), and both function/global

Re: Primary keepalive message not appearing in Logical Streaming Replication

On Sun, Sep 15, 2019 at 11:44 AM Michael Loftis wrote: > > > On Sun, Sep 15, 2019 at 08:36 Virendra Negi wrote: > >> Oh I miss the documentation link there you go >> https://www.postgresql.org/docs/9.5/protocol-replication.html >> >> On Sun, Sep 15, 2019 at 8:05 PM Virendra Negi >> wrote: >>

Re: log spam with postgres_fdw

On Sun, Sep 15, 2019 at 11:14 AM Tom Lane wrote: > Jeff Janes writes: > > When closing the local session which had used postgres_fdw over an ssl > > connection, I get log spam on the foreign server saying: > > LOG: could not receive data from client: Connection reset b

log spam with postgres_fdw

I'm sending this to hackers, because it is not exactly a bug, and it can't be addressed from userland. I think it is a coding issue, although I haven't identified the exact code. When closing the local session which had used postgres_fdw over an ssl connection, I get log spam on the foreign

pg_basebackup delays closing of stdout

Ever since pg_basebackup was created, it had a comment like this: * End of chunk. If requested, and this is the base tablespace * write configuration file into the tarfile. When done, close the * file (but not stdout). But, why make the exception for output going to stdout? If we

Re: [PATCH] Race condition in logical walsender causes long postgresql shutdown delay

On Wed, Sep 11, 2019 at 3:52 PM Alvaro Herrera wrote: > > Reading over this code, I noticed that the detection of the catch-up > state ends up being duplicate code, so I would rework that function as > in the attached patch. > > The naming of those flags (got_SIGUSR2, got_STOPPING) is terrible,

DROP SUBSCRIPTION with no slot

I recently had to cut loose (pg_drop_replication_slot) a logical replica that couldn't keep up and so was threatening to bring down the master. In mopping up on the replica side, I couldn't just drop the subscription, because it couldn't drop the nonexistent slot on the master and so refused to

JSONPATH documentation

I find the documentation in https://www.postgresql.org/docs/12/functions-json.html very confusing. In table 9.44 take the first entry, Example JSON {"x": [2.85, -14.7, -9.4]} Example Query + $.x.floor() Result 2, -15, -10 There are no end to end examples here. How do I apply the example

Re: WAL recycled despite logical replication slot

On Fri, Sep 20, 2019 at 11:27 AM Tomas Vondra wrote: > > > >Is there an innocent explanation for this? I thought logical replication > >slots provided an iron-clad guarantee that WAL would be retained until it > >was no longer needed. I am just using pub/sub, none of the lower level > >stuff.

  1   2   >