Re: Zedstore - compressed in-core columnar storage

On 23/05/19 12:07 PM, Ashwin Agrawal wrote: We (Heikki, me and Melanie) are continuing to build Zedstore. Wish to share the recent additions and modifications. Attaching a patch with the latest code. Link to github branch [1] to follow along. The approach we have been leaning towards is to

Re: Performance issue in foreign-key-aware join estimation

On Fri, 22 Mar 2019 at 10:10, Tom Lane wrote: > > David Rowley writes: > > [ eclass_indexes_v4.patch ] > > I still don't like this approach too much. I think we can fairly easily > construct the eclass_indexes at a higher level instead of trying to > manage them in add_eq_member, and after some

Re: POC: converting Lists into arrays

On Sat, 25 May 2019 at 12:53, Tom Lane wrote: > Now, it turns out that the new formulation of foreach() is really > strictly equivalent to > > for (int pos = 0; pos < list_length(list); pos++) > { > whatever-type item = list_nth(list, pos); > ... >

Re: Fix link for v12

On Thu, May 23, 2019 at 10:56 PM Euler Taveira wrote: > > Hi, > > I noticed that v12 release notes is referencing the wrong GUC. It > should be recovery_target_timeline instead of recovery_target_time. > Patch attached. > Your patch looks correct to me. I will commit it in some time unless

Re: Confusing error message for REINDEX TABLE CONCURRENTLY

On Sat, 25 May 2019 at 12:06, Ashwin Agrawal wrote: > Seems might be just emit the NOTICE "table xxx has no index", if really no > index for concurrent and non-concurrent case, make it consistent, less > confusing and leave it there. Attaching the patch to just do that. Thoughts? Would it not

Re: [HACKERS] WAL logging problem in 9.4.3?

On Mon, May 20, 2019 at 03:54:30PM +0900, Kyotaro HORIGUCHI wrote: > Following this direction, the attached PoC works *at least for* > the wal_optimization TAP tests, but doing pending flush not in > smgr but in relcache. This task, syncing files created in the current transaction, is not the

Re: POC: converting Lists into arrays

Here's a new version of the Lists-as-arrays patch. It's rebased up to HEAD, and I also realized that I could fix the problem with multiple evaluation of the List arguments of foreach etc. by using structure assignment. So that gets rid of a large chunk of the semantic gotchas that were in the

Re: Indexing - comparison of tree structures

T-tree (and variants) are index types commonly associated with in-memory database management systems and rarely, if-ever, used with on-disk databases. There has been a lot of research in regard to more modern cache conscious/oblivious b-trees that perform equally or better than t-tree. What’s the

Confusing error message for REINDEX TABLE CONCURRENTLY

CREATE TABLE circles (c circle, EXCLUDE USING gist (c WITH &&)); REINDEX TABLE CONCURRENTLY circles; WARNING: cannot reindex exclusion constraint index "public.circles_c_excl" concurrently, skipping NOTICE: table "circles" has no indexes REINDEX The message "table has no indexes" is confusing,

Re: Suppressing noise in successful check-world runs

On Fri, May 24, 2019 at 4:18 PM Tom Lane wrote: > Yes, I see that too with sufficiently high -j. I believe this is > what Noah was trying to fix in bd1592e85, but that patch evidently > needs a bit more work :-( It would be nice if this was fixed, but I don't see a problem when I use the

Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL

On 5/24/19 11:22 AM, Andres Freund wrote: > Hi, > > On 2019-05-22 13:08:41 -0700, Andres Freund wrote: >> On 2019-05-22 16:04:34 -0400, Andrew Dunstan wrote: >>> If I disable install, the buildfarm fails the upgrade check even when >>> not using NO_TEMP_INSTALL. >>> >>> >>> excerpts from the

Re: Suppressing noise in successful check-world runs

Peter Geoghegan writes: > My development machine has 8 logical cores, and like you I only see > the NOTICE from pg_upgrade's tests with "-j10": > pg@bat:/code/postgresql/patch/build$ time make check-world -j10 >/dev/null > NOTICE: database "regression" does not exist, skipping > make

Re: POC: GROUP BY optimization

On Fri, May 24, 2019 at 02:10:48PM +0200, Dmitry Dolgov wrote: On Fri, May 3, 2019 at 11:55 PM Tomas Vondra wrote: I don't recall the exact details of the discussion, since most of it happened almost a year ago, but the main concern about the original costing approach is that it very much

Re: [HACKERS] Runtime Partition Pruning

On Fri, May 24, 2019 at 09:24:28AM -0700, Andres Freund wrote: Hi, On 2019-05-24 12:08:57 -0400, Tom Lane wrote: Andres Freund writes: > On 2019-05-24 11:34:58 -0400, Tom Lane wrote: >> Hmm, after some digging in the archives, the closest thing I can find >> is this thread: >>

Re: Zedstore - compressed in-core columnar storage

On Thu, May 23, 2019 at 7:30 PM Ajin Cherian wrote: > Hi Ashwin, > > - how to pass the "column projection list" to table AM? (as stated in > initial email, currently we have modified table am API to pass the > projection to AM) > > We were working on a similar columnar storage using

Question about some changes in 11.3

Hi, 11.3 included some change to partition table planning. Namely commit 925f46f ("Fix handling of targetlist SRFs when scan/join relation is known empty.") seems to redo all paths for partitioned tables in apply_scanjoin_target_to_paths. It clears the paths in: ``` if (rel_is_partitioned)

Re: Suppressing noise in successful check-world runs

On Fri, May 24, 2019 at 12:31 PM Peter Geoghegan wrote: > > On Wed, May 22, 2019 at 3:57 PM Tom Lane wrote: > > I experimented with the attached quick-hack patch to make pg_regress > > suppress notices from its various initial DROP/CREATE IF [NOT] EXISTS > > commands. I'm not entirely convinced

Re: Suppressing noise in successful check-world runs

On Wed, May 22, 2019 at 3:57 PM Tom Lane wrote: > I experimented with the attached quick-hack patch to make pg_regress > suppress notices from its various initial DROP/CREATE IF [NOT] EXISTS > commands. I'm not entirely convinced whether suppressing them is > a good idea though. Perhaps some

Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)

On Sat, May 25, 2019 at 2:19 AM Sean Johnston wrote: > Obviously this isn't mainstream postgres but just wondering if anyone has > looked into issues with regards to pushing order/limit to remote nodes for > fdw. In PostgreSQL 12 Beta 1 released this week [1], we can push down ORDER BY/LIMIT

Generated columns and indexes

The documentation for generated columns should probably say whether you can create indexes on them.

Nitpick about assumptions in indexam and tableam

Hackers, The return value of RegisterSnapshot is being ignored in a few places in indexam.c and tableam.c, suggesting an intimate knowledge of the inner workings of the snapshot manager from these two files. I don't think that is particularly wise, and I don't see a performance justification for

Re: proposal: new polymorphic types - commontype and commontypearray

Hi út 5. 3. 2019 v 18:37 odesílatel Pavel Stehule napsal: > > > út 5. 3. 2019 v 15:35 odesílatel Tom Lane napsal: > >> David Steele writes: >> > This thread has been very quiet for a month. I agree with Andres [1] >> > that we should push this to PG13. >> >> I think the main thing it's

Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)

Sean Johnston writes: > Not sure if this is the right avenue to follow up on this. The patch works > fine. However, we're working on a modified version of the postgres_fdw in > which we're trying to push as much as possible to the remote nodes, > including ordering and limits. The patch causes

Re: BUG #15781: subselect on foreign table (postgres_fdw) can crash (segfault)

Not sure if this is the right avenue to follow up on this. The patch works fine. However, we're working on a modified version of the postgres_fdw in which we're trying to push as much as possible to the remote nodes, including ordering and limits. The patch causes the upper paths for the ordering

Re: [HACKERS] proposal: schema variables

Hi čt 9. 5. 2019 v 6:34 odesílatel Pavel Stehule napsal: > Hi > > rebased patch > rebase after pgindent Regards Pavel > > Regards > > Pavel > > > schema-variables-20190524.patch.gz Description: application/gzip

Re: Read-only access to temp tables for 2PC transactions

Hi, On 2019-05-24 19:37:15 +0300, Konstantin Knizhnik wrote: > From my point of view releasing all temporary table locks after preparing of > 2PC transaction is not technically possible: > assume that this transaction has  updated some tuples of temporary table - > them > are not visible to

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 10:28 AM, Tom Lane wrote: > Joe Conway writes: >> On 5/24/19 9:33 AM, David Rowley wrote: >>> For it to have regressed it would have had to once have been better, >>> but where was that mentioned? The only thing I saw was >>> non-partitioned tables compared to partitioned tables, but

Re: Inconsistency between table am callback and table function names

On Thu, May 23, 2019 at 4:32 PM Andres Freund wrote: > Hi, > > On 2019-05-14 12:11:46 -0700, Ashwin Agrawal wrote: > > Thank you. Please find the patch to rename the agreed functions. It would > > be good to make all consistent instead of applying exception to three > > functions but seems no

Re: Read-only access to temp tables for 2PC transactions

On 24.05.2019 11:52, Simon Riggs wrote: On Fri, 24 May 2019 at 01:39, Michael Paquier > wrote: On Thu, May 23, 2019 at 08:54:59AM -0700, Andres Freund wrote: > On 2019-05-23 12:36:09 +0100, Simon Riggs wrote: >> The ONLY case where this matters is if

Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()

I wrote: > didier writes: >> Without this patch make check fails 3 tests if pg is compiled with >> -fsanitize=address,undefined > ... but if that's the only evidence of an actual problem, I can't > get excited about it. ASAN complains about many things in Postgres, > and most of them are pretty

Re: [HACKERS] Runtime Partition Pruning

Hi, On 2019-05-24 12:08:57 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-05-24 11:34:58 -0400, Tom Lane wrote: > >> Hmm, after some digging in the archives, the closest thing I can find > >> is this thread: > >>

Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()

Hi, On Fri, May 24, 2019 at 5:10 PM Tom Lane wrote: > > didier writes: > > A smaller version removing memset in print_aligned_text function. > > The line is redundant , header_done isn't used yet and it's either > > pg_malloc0 or null. > > Hm, I see the theoretical problem ... > > > Without

Re: [HACKERS] Runtime Partition Pruning

Andres Freund writes: > On 2019-05-24 11:34:58 -0400, Tom Lane wrote: >> Hmm, after some digging in the archives, the closest thing I can find >> is this thread: >> https://www.postgresql.org/message-id/flat/CAMsr%2BYGL%2ByfWE%3DJvbUbnpWtrRZNey7hJ07%2BzT4bYJdVp4Szdrg%40mail.gmail.com >> where we

Re: [HACKERS] Runtime Partition Pruning

Hi, On 2019-05-24 11:34:58 -0400, Tom Lane wrote: > I wrote: > > Peter Eisentraut writes: > >> What do people think about adding something like this errbacktrace() > >> from Álvaro's patch to core PostgreSQL? > > > I think we did discuss it right after that, or somewhere nearby, and > >

Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL

Andres Freund writes: > Andrew, after the latest set of changes, the reversed order should now > work reliably? Also, Thomas should be able to revert his cfbot hack ... regards, tom lane

Re: [HACKERS] Runtime Partition Pruning

I wrote: > Peter Eisentraut writes: >> What do people think about adding something like this errbacktrace() >> from Álvaro's patch to core PostgreSQL? > I think we did discuss it right after that, or somewhere nearby, and > concluded that the output is so imprecise that it's not really going >

Re: Minimal logical decoding on standbys

On Fri, 24 May 2019 at 19:26, Amit Khandekar wrote: > Working on the patch now Attached is an incremental WIP patch handle_wal_level_changes_WIP.patch to be applied over the earlier main patch logical-decoding-on-standby_v4_rebased.patch. > > > > On 2019-05-21 09:19:37 -0700, Andres Freund

Re: initdb recommendations

On Thu, May 23, 2019 at 06:56:49PM +0200, Magnus Hagander wrote: > On Thu, May 23, 2019, 18:54 Peter Eisentraut > wrote: > > To recap, the idea here was to change the default authentication methods > > that initdb sets up, in place of "trust". > > > > I think the ideal scenario would be to use

Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL

Hi, On 2019-05-22 13:08:41 -0700, Andres Freund wrote: > On 2019-05-22 16:04:34 -0400, Andrew Dunstan wrote: > > If I disable install, the buildfarm fails the upgrade check even when > > not using NO_TEMP_INSTALL. > > > > > > excerpts from the log: > > sh:

Re: [HACKERS] Runtime Partition Pruning

Peter Eisentraut writes: > On 2018-04-10 23:32, Alvaro Herrera wrote: >> To figure out, I used the attached patch (not intended for application) >> to add a backtrace to each log message, plus a couple of accusatory >> elog() calls in relation_open and ExecSetupPartitionPruneState. > What do

Contribute - money

Hi, Is it possible to obtain money for a contribution I give hear. Or is everything expected to be free? Regards Sascha Kuhl

Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()

didier writes: > A smaller version removing memset in print_aligned_text function. > The line is redundant , header_done isn't used yet and it's either > pg_malloc0 or null. Hm, I see the theoretical problem ... > Without this patch make check fails 3 tests if pg is compiled with >

Re: initdb recommendations

On 5/24/19 10:26 AM, Heikki Linnakangas wrote: > On 24/05/2019 17:02, Jonathan S. Katz wrote: >> On 5/24/19 9:49 AM, Heikki Linnakangas wrote: >>> It just prevents MD5 authentication in case a user forces a >>> new MD5 hash into the system e.g. by changing password_encryption, or by >>> setting an

Re: [HACKERS] Runtime Partition Pruning

On 2018-04-10 23:32, Alvaro Herrera wrote: > To figure out, I used the attached patch (not intended for application) > to add a backtrace to each log message, plus a couple of accusatory > elog() calls in relation_open and ExecSetupPartitionPruneState. What do people think about adding something

Re: BUG #15819: wrong expression in document of pgbench

In example of random_zipfian, the explanation is "which itself(2) is produced (3/2)*2.5 = 2.76 times more frequently than 3". "(3/2)*2.5 = 2.76" is wrong. The correct expression is "(3/2)**2.5 = 2.76". Indeed. Attached patch to fix this typo. -- Fabiendiff --git

Re: Excessive memory usage in multi-statement queries w/ partitioning

Joe Conway writes: > On 5/24/19 9:33 AM, David Rowley wrote: >> For it to have regressed it would have had to once have been better, >> but where was that mentioned? The only thing I saw was >> non-partitioned tables compared to partitioned tables, but you can't >> really say it's a regression

Re: initdb recommendations

On 24/05/2019 17:02, Jonathan S. Katz wrote: On 5/24/19 9:49 AM, Heikki Linnakangas wrote: It just prevents MD5 authentication in case a user forces a new MD5 hash into the system e.g. by changing password_encryption, or by setting an MD5 password explicitly with ALTER USER. Cool. Thanks for

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 9:33 AM, David Rowley wrote: > On Sat, 25 May 2019 at 00:18, Joe Conway wrote: >> I admittedly haven't followed this thread too closely, but if having 100 >> partitions causes out of memory on pg11, that sounds like a massive >> regression to me. > > For it to have regressed it would

Re: initdb recommendations

On 5/24/19 9:49 AM, Heikki Linnakangas wrote: > On 24/05/2019 16:01, Stephen Frost wrote: >> What I was really getting at though was the ability to have multiple >> authenticator tokens active concurrently (eg: md5 AND SCRAM), with an >> ability to use either one (idk, md5_or_scram auth method?),

Re: initdb recommendations

Greetings, * Heikki Linnakangas (hlinn...@iki.fi) wrote: > On 24/05/2019 16:01, Stephen Frost wrote: > >What I was really getting at though was the ability to have multiple > >authenticator tokens active concurrently (eg: md5 AND SCRAM), with an > >ability to use either one (idk, md5_or_scram

Re: Minimal logical decoding on standbys

On Thu, 23 May 2019 at 23:18, Andres Freund wrote: > > Hi, > > On 2019-05-23 23:08:55 +0530, Amit Khandekar wrote: > > On Thu, 23 May 2019 at 21:29, Andres Freund wrote: > > > On 2019-05-23 17:39:21 +0530, Amit Khandekar wrote: > > > > On Tue, 21 May 2019 at 21:49, Andres Freund wrote: > > > >

Re: initdb recommendations

On 24/05/2019 16:01, Stephen Frost wrote: What I was really getting at though was the ability to have multiple authenticator tokens active concurrently (eg: md5 AND SCRAM), with an ability to use either one (idk, md5_or_scram auth method?), and then automatically set both on password change

Re: Aggregate error message

David Rowley writes: > On Fri, 24 May 2019 at 18:17, Vik Fearing wrote: >> With a sample query such as >> SELECT x, avg(x) >> FROM (VALUES (1), (2), (3)) AS v (x); >> We give the error message "column "v.x" must appear in the GROUP BY >> clause or be used in an aggregate function". >> This is

Re: Excessive memory usage in multi-statement queries w/ partitioning

On Sat, 25 May 2019 at 00:18, Joe Conway wrote: > I admittedly haven't followed this thread too closely, but if having 100 > partitions causes out of memory on pg11, that sounds like a massive > regression to me. For it to have regressed it would have had to once have been better, but where was

Re: initdb recommendations

On 5/24/19 9:01 AM, Stephen Frost wrote: > Greetings, > > * Jonathan S. Katz (jk...@postgresql.org) wrote: >> On 5/24/19 8:33 AM, Stephen Frost wrote: >>> We need to provide better documentation about how to get from md5 to >>> SCRAM, in my view. I'm not sure where that should live, exactly. >>>

Re: initdb recommendations

On 5/24/19 8:56 AM, Jonathan S. Katz wrote: > On 5/24/19 8:33 AM, Stephen Frost wrote: >> * Magnus Hagander (mag...@hagander.net) wrote: >>> Making the default change away from trust in the source distro will affect >>> few people. >> >> Agreed. > > +1 Fewer people, but likely

Re: initdb recommendations

Greetings, * Jonathan S. Katz (jk...@postgresql.org) wrote: > On 5/24/19 8:33 AM, Stephen Frost wrote: > > We need to provide better documentation about how to get from md5 to > > SCRAM, in my view. I'm not sure where that should live, exactly. > > I really wish we had put more effort into

Re: initdb recommendations

On 5/24/19 8:33 AM, Stephen Frost wrote: > Greetings, > > * Magnus Hagander (mag...@hagander.net) wrote: >> The thing that will potentially hit *end users* is when the RPMs, DEBs or >> Windows Installers switch to SCRAM (because of clients with older drivers). > > Agreed. I'm not sure that our

Re: initdb recommendations

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > The thing that will potentially hit *end users* is when the RPMs, DEBs or > Windows Installers switch to SCRAM (because of clients with older drivers). Agreed. I'm not sure that our change to SCRAM as default would actually make them

Re: initdb recommendations

On Fri, May 24, 2019 at 2:19 PM Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: > > On 5/24/19 8:13 AM, Stephen Frost wrote: > > > * Joe Conway (m...@joeconway.com) wrote: > > >> On 5/23/19 10:30 PM, Stephen Frost wrote: > > >> > * Tom Lane (t...@sss.pgh.pa.us)

Re: Excessive memory usage in multi-statement queries w/ partitioning

On 5/24/19 1:47 AM, Amit Langote wrote: > On 2019/05/23 4:15, Andreas Seltenreich wrote: >> …but when doing it on the parent relation, even 100 statements are >> enough to exceed the limit: >> >> , >> | $ psql -c "$(yes update t set c=c where c=6 \; | head -n 100)" >> | FEHLER: Speicher

Re: initdb recommendations

Greetings, * Joe Conway (m...@joeconway.com) wrote: > On 5/24/19 8:13 AM, Stephen Frost wrote: > > * Joe Conway (m...@joeconway.com) wrote: > >> On 5/23/19 10:30 PM, Stephen Frost wrote: > >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> >> "Jonathan S. Katz" writes: > >> >> > For now I have

Re: initdb recommendations

On 5/24/19 8:13 AM, Stephen Frost wrote: > Greetings, > > * Joe Conway (m...@joeconway.com) wrote: >> On 5/23/19 10:30 PM, Stephen Frost wrote: >> > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> "Jonathan S. Katz" writes: >> >> > For now I have left in the password based method to be

Re: initdb recommendations

Greetings, * Joe Conway (m...@joeconway.com) wrote: > On 5/23/19 10:30 PM, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> "Jonathan S. Katz" writes: > >> > For now I have left in the password based method to be scram-sha-256 as > >> > I am optimistic about the support

Re: POC: GROUP BY optimization

> On Fri, May 3, 2019 at 11:55 PM Tomas Vondra > wrote: > > I don't recall the exact details of the discussion, since most of it > happened almost a year ago, but the main concern about the original > costing approach is that it very much assumes uniform distribution. > > For example if you have

Re: initdb recommendations

On 2019-05-24 13:48, Joe Conway wrote: > Are we doing this for pg12? no -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: initdb recommendations

On Fri, 24 May 2019 at 07:48, Joe Conway wrote: > On 5/23/19 10:30 PM, Stephen Frost wrote: > > Greetings, > > > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> "Jonathan S. Katz" writes: > >> > For now I have left in the password based method to be scram-sha-256 > as > >> > I am optimistic about

Re: initdb recommendations

On 5/23/19 10:30 PM, Stephen Frost wrote: > Greetings, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> "Jonathan S. Katz" writes: >> > For now I have left in the password based method to be scram-sha-256 as >> > I am optimistic about the support across client drivers[1] (and FWIW I >> > have an

Re: Converting NOT IN to anti-joins during planning

On Wed, 6 Mar 2019 at 12:54, David Rowley wrote: > The latest patch is attached. Rebased version after pgindent run. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services not_in_anti_join_v1.4.patch Description: Binary data

Re: Should we warn against using too many partitions?

On Fri, 24 May 2019 at 17:58, Amit Langote wrote: > + Whether using table inheritance or native partitioning, hierarchies > > Maybe, it would better to use the word "declarative" instead of "native", > if only to be consistent; neighboring paragraphs use "declarative". Thanks for having a

Indexing - comparison of tree structures

Hi, I compared two data structures realistically by time, after estimating big O. T-tree outperforms b-tree, which is commonly used, for a medium size table. Lehmann and Carey showed the same, earlier. Can you improve indexing by this? Understandably Sascha Kuhl Just another bit faster.pdf

Re: Read-only access to temp tables for 2PC transactions

On Fri, 24 May 2019 at 01:39, Michael Paquier wrote: > On Thu, May 23, 2019 at 08:54:59AM -0700, Andres Freund wrote: > > On 2019-05-23 12:36:09 +0100, Simon Riggs wrote: > >> The ONLY case where this matters is if someone does a PREPARE and then > >> starts doing other work on the session.

Re: Read-only access to temp tables for 2PC transactions

On Thu, 23 May 2019 at 16:55, Andres Freund wrote: > Hi, > > On 2019-05-23 12:36:09 +0100, Simon Riggs wrote: > > The ONLY case where this matters is if someone does a PREPARE and then > > starts doing other work on the session. Which makes no sense in the > normal > > workflow of a session. I'm

Re: Why does not subquery pruning conditions inherit to parent query?

On Fri, 24 May 2019 at 19:44, Kato, Sho wrote: > I execute following query to the partitioned table, but the plan is different > from my assumption, so please tell me the reason. > > postgres=# explain select * from jta, (select a, max(b) from jtb where a = 1 > group by a ) c1 where jta.a =

Why does not subquery pruning conditions inherit to parent query?

Hello I execute following query to the partitioned table, but the plan is different from my assumption, so please tell me the reason. postgres=# explain select * from jta, (select a, max(b) from jtb where a = 1 group by a ) c1 where jta.a = c1.a; QUERY PLAN

Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()

Hi A smaller version removing memset in print_aligned_text function. The line is redundant , header_done isn't used yet and it's either pg_malloc0 or null. Without this patch make check fails 3 tests if pg is compiled with -fsanitize=address,undefined diff --git a/src/fe_utils/print.c

Re: Aggregate error message

On Fri, 24 May 2019 at 18:17, Vik Fearing wrote: > > With a sample query such as > > SELECT x, avg(x) > FROM (VALUES (1), (2), (3)) AS v (x); > > We give the error message "column "v.x" must appear in the GROUP BY > clause or be used in an aggregate function". > > This is correct but incomplete.

Aggregate error message

With a sample query such as SELECT x, avg(x) FROM (VALUES (1), (2), (3)) AS v (x); We give the error message "column "v.x" must appear in the GROUP BY clause or be used in an aggregate function". This is correct but incomplete. Attached is a trivial patch to also suggest that the user might