Re: Ordered Partitioned Table Scans

On Thu, 31 Jan 2019 at 16:29, David Rowley wrote: > I've attached a rebased patch which fixes up the recent conflicts. No > other changes were made. Rebased version due to a new call to create_append_path() added in ab5fcf2b0. No other changes made. -- David Rowley

POC: converting Lists into arrays

For quite some years now there's been dissatisfaction with our List data structure implementation. Because it separately palloc's each list cell, it chews up lots of memory, and it's none too cache-friendly because the cells aren't necessarily adjacent. Moreover, our typical usage is to just

Re: \describe*

Hi, On 2019-02-23 19:14:27 -0500, Corey Huinker wrote: > > > > Given that this patch has been added to the last commitfest for v12, I > > think we should mark it as targeting 13, so it can be skipped over by > > people looking to get things into v12. Even leaving fairness aside, I > > don't

Re: \describe*

> > Given that this patch has been added to the last commitfest for v12, I > think we should mark it as targeting 13, so it can be skipped over by > people looking to get things into v12. Even leaving fairness aside, I > don't think it's likely to be ready quickly enough... > Obviously this

Re: some ri_triggers.c cleanup

On Fri, Feb 22, 2019 at 1:12 PM Corey Huinker wrote: > On Fri, Feb 22, 2019 at 11:05 AM Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > >> ri_triggers.c is endlessly long and repetitive. I want to clean it up a >> bit (more). >> > > Having just been down this road, I agree that

Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 04:29:24PM +0100, Magnus Hagander wrote: > On Sat, Feb 23, 2019 at 4:18 PM Michael Paquier wrote: >> Perhaps I am missing something, but it would be just more simple to >> now allow users to restrict that? >> > > I can't parse what you are saying here. Now allow users to

Re: explain plans with information about (modified) gucs

Hi, attached is an updated patch, fixing and slightly tweaking the docs. Barring objections, I'll get this committed later next week. -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >From

Re: WIP: BRIN multi-range indexes

deciding the > parameter - in this case, it's "number of values per range". Again, it's > a compromise vs. index size and efficiency. The default (64 values) is > fairly reasonable, but ultimately it's up to the user - there is a new > reloption "values_per_range". >

Re: FETCH FIRST clause PERCENT option

On 2/23/19 8:53 AM, Surafel Temesgen wrote: > > > On Sun, Feb 10, 2019 at 2:22 AM Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote: >   > > > I'm not sure I understand - are you saying every time the user does a > FETCH, we have to run the outer plan from scratch? I don't

Re: [patch] Add schema total size to psql \dn+

On Fri, Feb 22, 2019 at 7:22 PM Tom Lane wrote: > > Is there any permissions issue involved here? I'd be a bit worried > about whether \dn+ could fail, or deliver misleading answers, when > run by a user without permissions on (some) tables. Also, even if > we allow people to get size info on

Re: proposal: variadic argument support for least, greatest function

On 02/23/19 13:35, Pavel Stehule wrote: > please, see, attached patch It is getting close, for my purposes. There is still this: >> Can the sentence added to the doc be changed to "These functions support >> passing parameters as an array after VARIADIC >> keyword."? That is, s/supports/support/

Re: proposal: variadic argument support for least, greatest function

so 23. 2. 2019 v 18:28 odesílatel Chapman Flack napsal: > On 02/23/19 01:22, Pavel Stehule wrote: > > so 23. 2. 2019 v 4:50 odesílatel Chapman Flack > > napsal: > > >> In transformMinMaxExpr: > >> The assignment of funcname doesn't look right. > > ... it still doesn't. > fixed > >> Two new

Re: proposal: variadic argument support for least, greatest function

On 02/23/19 01:22, Pavel Stehule wrote: > so 23. 2. 2019 v 4:50 odesílatel Chapman Flack > napsal: >> In transformMinMaxExpr: >> The assignment of funcname doesn't look right. ... it still doesn't. >> Two new errors are elogs. ... >> I am not sure if there is a way for user input to trigger

Re: [PATCH v20] GSSAPI encryption support

Greetings, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > I don't know much about GSSAPI, but from what I can tell, this seems an > attractive feature, and the implementation is compact enough. I have > done a bit of work on the internal SSL API refactoring, so I have some >

Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 5:01 PM Tom Lane wrote: > Magnus Hagander writes: > > I think we're better off just peventing the explicit drop of a temp > schema. > > See attached? > > I think this is a poor implementation of a bad idea. Would you like a > list of the ways a superuser can break the

Re: Autovaccuum vs temp tables crash

Magnus Hagander writes: > I think we're better off just peventing the explicit drop of a temp schema. > See attached? I think this is a poor implementation of a bad idea. Would you like a list of the ways a superuser can break the system? We could start with "DELETE FROM pg_proc;".

Re: Autovaccuum vs temp tables crash

Magnus Hagander writes: > On Fri, Feb 22, 2019 at 7:15 PM Robert Haas wrote: >> On Fri, Feb 22, 2019 at 1:14 PM Tom Lane wrote: >>> Note that all the temp schemas are made as owned by the bootstrap >>> superuser, so there is no real argument to be made that people might >>> be expecting they

Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 4:28 PM Magnus Hagander wrote: > > > On Sat, Feb 23, 2019 at 12:29 AM Michael Paquier > wrote: > >> On Fri, Feb 22, 2019 at 09:45:42AM -0500, Tom Lane wrote: >> > +1 ... maybe "(dropped)", because we tend to use parens for this sort >> > of thing, I think. >> >> +1.

Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 4:18 PM Michael Paquier wrote: > On Sat, Feb 23, 2019 at 02:48:58PM +0100, Magnus Hagander wrote: > > I think we need to either prevent dropping of temp namespaces *or* we > need > > to create a new entry in pg_namespace in this particular case. > > Perhaps I am missing

Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 12:29 AM Michael Paquier wrote: > On Fri, Feb 22, 2019 at 09:45:42AM -0500, Tom Lane wrote: > > +1 ... maybe "(dropped)", because we tend to use parens for this sort > > of thing, I think. > > +1. Using "dropped" sounds good to me in this context. Perhaps we > could

Re: Autovaccuum vs temp tables crash

On Sat, Feb 23, 2019 at 02:48:58PM +0100, Magnus Hagander wrote: > I think we need to either prevent dropping of temp namespaces *or* we need > to create a new entry in pg_namespace in this particular case. Perhaps I am missing something, but it would be just more simple to now allow users to

Re: FOP warnings about id attributes in title tags

On 2/22/19 9:57 AM, Andrew Dunstan wrote: > On 2/19/19 11:07 AM, Peter Eisentraut wrote: >> On 2019-02-18 16:37, Peter Eisentraut wrote: It appears that these are due to title elements having id tags. At is says: When

Re: oddity with ALTER ROLE/USER

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Joe Conway writes: > > I noticed that ALTER ROLE/USER succeeds even when called without any > > options: > > > postgres=# alter user foo; > > ALTER ROLE > > postgres=# alter role foo; > > ALTER ROLE > > postgres=# alter group foo; > > ERROR:

Re: Autovaccuum vs temp tables crash

On Fri, Feb 22, 2019 at 7:15 PM Robert Haas wrote: > On Fri, Feb 22, 2019 at 1:14 PM Tom Lane wrote: > > Why? It would likely be a significant amount of effort and added > overhead, > > to accomplish no obviously-useful goal. > > > > Note that all the temp schemas are made as owned by the

Re: [HACKERS] Block level parallel vacuum

On Thu, Feb 14, 2019 at 9:17 PM Masahiko Sawada wrote: > On Wed, Feb 13, 2019 at 9:32 PM Haribabu Kommi > wrote: > > > > > > On Sat, Feb 9, 2019 at 11:47 PM Masahiko Sawada > wrote: > >> > >> On Tue, Feb 5, 2019 at 12:14 PM Haribabu Kommi < > kommi.harib...@gmail.com> wrote: > >> > > >> > > >>

Re: [Bug Fix] ECPG: could not use set xxx to default statement

> Not seeing any motion on this, here's a draft patch to make these > scripts complain about missing semicolons. Against the current > gram.y (which contains 2 such errors, as Michael noted) you > get output like Thanks Tom for looking into this. Are we agreed then that we want gram.y to have

Re: [PATCH v20] GSSAPI encryption support

I don't know much about GSSAPI, but from what I can tell, this seems an attractive feature, and the implementation is compact enough. I have done a bit of work on the internal SSL API refactoring, so I have some thoughts on this patch. Looking at the file structure, we would have be-secure.c

Re: Add --include-table-data-where option to pg_dump, to export only a subset of table data

On Thu, Jan 31, 2019 at 10:22 PM Carter Thaxton wrote: > > > Here's a rebased patch that works with the latest master branch. Very > straightforward. > You forget to resubmit it to the next commitfest and the error message on incorrect where clause specification is still the same regards

Re: Why don't we have a small reserved OID range for patch revisions?

I wrote: > Along those lines, here's a draft patch to do just that. It handles > array type oids as well. Run it like this: > > perl reformat_dat_file.pl --map-from 9000 --map-to 2000 *.dat > > There is some attempt at documentation. So far it doesn't map by > default, but that could be

Re: WIP: Avoid creation of the free space map for small tables

On Fri, Feb 22, 2019 at 3:59 AM Amit Kapila wrote: > The reason for not pushing much on making the test pass for > nonstandard block sizes is that when I tried existing tests, there > were already some failures. FWIW, I currently see 8 failures (attached). -- John Naylor