[HACKERS] New design for FK-based join selectivity estimation

This is a branch of the discussion in https://www.postgresql.org/message-id/flat/20160429102531.GA13701%40huehner.biz but I'm starting a new thread as the original title is getting increasingly off-topic. I complained in that thread that the FK join selectivity patch had a very brute-force

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

Robert Haas writes: > FYI, I spoke to Tom Lane about this at PGCon and suggested that he > look at the proposed patch as I requested in > https://www.postgresql.org/message-id/CA+TgmobPqrAVXOBMHTcpDq8hX7gCzcVhoUvC8s9V=d09+bt...@mail.gmail.com > and see whether that would

Re: [HACKERS] COMMENT ON, psql and access methods

On Thu, Jun 02, 2016 at 04:00:33PM +0900, Michael Paquier wrote: > On Thu, Jun 2, 2016 at 3:42 PM, Michael Paquier > wrote: > > On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier > > wrote: > >> I have added an open item for 9.6 regarding this

Re: [HACKERS] regexp_match() returning text

On Saturday, June 4, 2016, Emre Hasegeli wrote: > > The main problem being solved is the use of a SETOF result. I'm > inclined to > > prefer that the final, single, result is still an array. > > I have changed it like that. New patch attached. Good > > > I've got a style

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner wrote: > Consequently, causing the index to be ignored in planning when > using the old index That last line should have read "using an old snapshot" > is not a nice optimization, but necessary for > correctness. We already

[HACKERS] Re: pg9.6 segfault using simple query (related to use fk for join estimates)

On Fri, Jun 03, 2016 at 10:32:24AM -0400, Noah Misch wrote: > On Wed, Jun 01, 2016 at 09:29:54PM -0400, Noah Misch wrote: > > On Sun, May 29, 2016 at 01:36:01AM -0400, Noah Misch wrote: > > > On Fri, May 06, 2016 at 03:06:01PM -0400, Robert Haas wrote: > > > > On Thu, May 5, 2016 at 10:48 AM,

Re: [HACKERS] pg9.6 segfault using simple query (related to use fk for join estimates)

David Rowley writes: > I think your wires are crossed to what this patch actually does. A > unique index could only prove that no more than 1 rows exists. This > goes to prove that exactly 1 exists, then will reduce that estimate by > any other join conditions which

Re: [HACKERS] NOT EXIST for PREPARE

On Friday, May 6, 2016, Robert Haas wrote: > On Fri, May 6, 2016 at 2:38 PM, Merlin Moncure > wrote: > > On Fri, Mar 25, 2016 at 8:36 AM, Merlin Moncure > wrote: > >> On Wed, Mar 23, 2016 at 3:10 PM,

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Tue, 22 Mar 2016 at 10:34 Robert Haas wrote: > Yeah, I think requiring PERFORM is stupid and annoying. +1 for > letting people write a SELECT with no target. > Apologies for being late on the thread, but another +1 from me. I've often been frustrated by the

Re: [HACKERS] Relax requirement for INTO with SELECT in pl/pgsql

On Tuesday, March 22, 2016, Merlin Moncure wrote: > > Anyways, here's the patch with documentation adjustments as promised. > I ended up keeping the 'without result' section because it contained > useful information about plan caching, > > merlin > > diff --git

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On Thursday, March 17, 2016, Craig Ringer wrote: > The first patch was incorrectly created on top of failover slots not HEAD. > Attached patch applies on HEAD. > Lots of logical decoding work ongoing but this one shows as active in the September cf and the comments by

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

On Sat, Jun 4, 2016 at 8:43 AM, Robert Haas wrote: > > On Thu, May 26, 2016 at 5:57 AM, Amit Kapila wrote: > > > > I am able to reproduce the assertion (it occurs once in two to three times, > > but always at same place) you have reported upthread

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

Michael Paquier writes: > This is still failing: > =# select indexdef from pg_catalog.pg_indexes where indexdef is not NULL; > ERROR: XX000: cache lookup failed for index 2619 > LOCATION: pg_get_indexdef_worker, ruleutils.c:1054 > Do we want to improve at least the

Re: [HACKERS] regexp_match() returning text

> The main problem being solved is the use of a SETOF result. I'm inclined to > prefer that the final, single, result is still an array. I have changed it like that. New patch attached. > I've got a style issue with the information_schema - I like to call it > useless-use-of-E'' - but that

Re: [HACKERS] [sqlsmith] Failed assertion in joinrels.c

On Fri, Aug 7, 2015 at 9:21 AM, Tom Lane wrote: > Andreas Seltenreich writes: >> Tom Lane writes: >>> On 08/01/2015 05:59 PM, Tom Lane wrote: Well, I certainly think all of these represent bugs: 1 | ERROR: could not find pathkey item to sort >