Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

2016-08-01 20:51 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 7/30/16 1:18 AM, Pavel Stehule wrote: > > We talked about this issue, when I wrote function pg_size_bytes. It is > > hard to fix these functions after years of usage. The new set of > > functions can be better >

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/08/02 13:32, Kouhei Kaigai wrote: I wrote: My concern here is EXPLAIN for foreign joins. I think it's another problem how we handle Foreign Scan plan nodes representing post-scan/join operations in EXPLAIN, so I'd like to leave that for another patch. What is the post-scan/join

Re: [HACKERS] Reviewing freeze map code

On Sat, Jul 23, 2016 at 01:25:55PM +0530, Amit Kapila wrote: > On Mon, Jul 18, 2016 at 2:03 PM, Andres Freund wrote: > > On 2016-07-18 10:02:52 +0530, Amit Kapila wrote: > >> Consider the below scenario. > >> > >> Vacuum > >> a. acquires a cleanup lock for page - 10 > >> b.

Re: [HACKERS] Wrong defeinition of pq_putmessage_noblock since 9.5

At Fri, 29 Jul 2016 11:58:04 -0400, Tom Lane wrote in <14846.1469807...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > The many of the socket_* functions are required to be replaced > > with mq_* functions for backgroud workers. So reverting

[HACKERS] Comment typo in tuplesort.c

Attached patch fixes a minor typo in tuplesort.c s/child content/child context/g Thanks, Amit diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c index 4c502bb..6756f26 100644 --- a/src/backend/utils/sort/tuplesort.c +++ b/src/backend/utils/sort/tuplesort.c @@

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

> On 2016/08/01 22:25, Kouhei Kaigai wrote: > > I wrote: > >>> a broader > >>> word like "Processing" seems to work well because we allow various > >>> kinds of operations to the remote side, in addition to scans/joins, > >>> to be performed in that one Foreign Scan node indicated

Re: [HACKERS] Wrong defeinition of pq_putmessage_noblock since 9.5

At Fri, 29 Jul 2016 13:00:50 -0400, Tom Lane wrote in <29430.1469811...@sss.pgh.pa.us> > I wrote: > > Kyotaro HORIGUCHI writes: > >> Any work in this area is likely 10.0 material at this point. > > > I'm not really happy with that, since

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/08/01 22:25, Kouhei Kaigai wrote: I wrote: a broader word like "Processing" seems to work well because we allow various kinds of operations to the remote side, in addition to scans/joins, to be performed in that one Foreign Scan node indicated by "Foreign

Re: [HACKERS] old_snapshot_threshold allows heap:toast disagreement

On Sat, Jul 30, 2016 at 8:17 AM, Amit Kapila wrote: > On Fri, Jul 29, 2016 at 1:10 AM, Robert Haas wrote: >> On Wed, Jul 27, 2016 at 7:26 PM, Andres Freund wrote: >> >> New version attached. > > +static inline void >

Re: [HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

On Mon, Aug 1, 2016 at 7:47 PM, Karan Sikka wrote: > I agree, should we remove it from the TODO list? If nobody objects, sure. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PostmasterContext survives into parallel workers!?

On Mon, Aug 1, 2016 at 7:42 PM, Tom Lane wrote: > Thomas Munro writes: >> I found this apparently unresolved bug report about glibc fork() >> inside a signal handler deadlocking: >> https://sourceware.org/bugzilla/show_bug.cgi?id=4737 > >> I

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Tue, Aug 2, 2016 at 2:08 AM, Robert Haas wrote: > Did you add this to the next CommitFest? I have added it here: https://commitfest.postgresql.org/10/691/ John, it would be good if you could get a community account and add your name to this patch as its author. I could

Re: [HACKERS] Increasing timeout of poll_query_until for TAP tests

On Wed, Jul 27, 2016 at 10:00 AM, Michael Paquier wrote: > On Mon, Jul 25, 2016 at 10:05 PM, Michael Paquier > wrote: >> On Mon, Jul 25, 2016 at 2:52 PM, Michael Paquier >> wrote: >>> Ah, yes, and that's a stupid

Re: [HACKERS] New version numbering practices

Michael Paquier wrote: > On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane wrote: > > Andrew Dunstan writes: > >> Somewhat related is how we name the git branches. It would help me from > >> a buildfarm POV if we kept lexically them sortable, which could be done >

Re: [HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

I agree, should we remove it from the TODO list? On Mon, Aug 1, 2016 at 6:13 PM, Robert Haas wrote: > On Mon, Aug 1, 2016 at 1:19 PM, Karan Sikka wrote: > > Following the patch to implement strpos with Boyer-Moore-Horspool, > > it was proposed we

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Thomas Munro writes: > I found this apparently unresolved bug report about glibc fork() > inside a signal handler deadlocking: > https://sourceware.org/bugzilla/show_bug.cgi?id=4737 > I wonder if that could bite postmaster. I seriously doubt it. The key thing

Re: [HACKERS] New version numbering practices

On Tue, Aug 2, 2016 at 5:25 AM, Tom Lane wrote: > Andrew Dunstan writes: >> Somewhat related is how we name the git branches. It would help me from >> a buildfarm POV if we kept lexically them sortable, which could be done >> at least for the next 90

Re: [HACKERS] PostmasterContext survives into parallel workers!?

On 2016-08-02 11:27:25 +1200, Thomas Munro wrote: > On Tue, Aug 2, 2016 at 10:28 AM, Tom Lane wrote: > > Andres Freund writes: > >> On 2016-08-01 18:09:03 -0400, Robert Haas wrote: > >>> (Also vaguely on the list of things to clean up: can't we make it so

Re: [HACKERS] PostmasterContext survives into parallel workers!?

On Tue, Aug 2, 2016 at 10:28 AM, Tom Lane wrote: > Andres Freund writes: >> On 2016-08-01 18:09:03 -0400, Robert Haas wrote: >>> (Also vaguely on the list of things to clean up: can't we make it so >>> that bgworkers aren't launched from inside a signal

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Andres Freund writes: > Personally I think the whole logic should be reworked so we do most of > that that only from one place. Alvaro already mentioned a couple of reasons why that might not be so easy. > Especially the signal handler stuff > should imo just be replaced by

Re: [HACKERS] PostmasterContext survives into parallel workers!?

On 2016-08-01 18:28:44 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-08-01 18:09:03 -0400, Robert Haas wrote: > >> (Also vaguely on the list of things to clean up: can't we make it so > >> that bgworkers aren't launched from inside a signal handler? Blech.) > >

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Tom Lane wrote: > Andres Freund writes: > > On 2016-08-01 18:09:03 -0400, Robert Haas wrote: > >> (Also vaguely on the list of things to clean up: can't we make it so > >> that bgworkers aren't launched from inside a signal handler? Blech.) > > > Isn't pretty much everything

Re: [HACKERS] Combining hash values

Robert Haas writes: > On Mon, Aug 1, 2016 at 11:27 AM, Tom Lane wrote: >> Perhaps, but this'd break existing hash indexes. That might not be >> a fatal objection, but if we're going to put users through that >> I'd like to think a little bigger in

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Andres Freund writes: > On 2016-08-01 18:09:03 -0400, Robert Haas wrote: >> (Also vaguely on the list of things to clean up: can't we make it so >> that bgworkers aren't launched from inside a signal handler? Blech.) > Isn't pretty much everything on-demand below postmaster

Re: [HACKERS] Combining hash values

On Mon, Aug 1, 2016 at 7:24 AM, Dean Rasheed wrote: > On 1 August 2016 at 08:19, Greg Stark wrote: >> Surely combining multiple hashes is the same problem as hashing a block of >> memory? Shouldn't we just use the same algorithm as hash_any()? > > Yes, I

Re: [HACKERS] Combining hash values

On Mon, Aug 1, 2016 at 11:27 AM, Tom Lane wrote: > Dean Rasheed writes: >> On that subject, while looking at hashfunc.c, I spotted that >> hashint8() has a very obvious deficiency, which causes disastrous >> performance with certain inputs: > > Well,

[HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

As some of you know, I've been working on parallel sort. I think I've gone as long as I can without feedback on the design (and I see that we're accepting stuff for September CF now), so I'd like to share what I came up with. This project is something that I've worked on inconsistently since late

Re: [HACKERS] PostmasterContext survives into parallel workers!?

Robert Haas writes: > (Also vaguely on the list of things to clean up: can't we make it so > that bgworkers aren't launched from inside a signal handler? Blech.) So are other postmaster children, I believe. We could probably try to rewrite the postmaster to not do useful

Re: [HACKERS] PostmasterContext survives into parallel workers!?

On 2016-08-01 18:09:03 -0400, Robert Haas wrote: > (Also vaguely on the list of things to clean up: can't we make it so > that bgworkers aren't launched from inside a signal handler? Blech.) Isn't pretty much everything on-demand below postmaster started from a signal handler? -- Sent via

Re: [HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

On Mon, Aug 1, 2016 at 1:19 PM, Karan Sikka wrote: > Following the patch to implement strpos with Boyer-Moore-Horspool, > it was proposed we bring BMH to LIKE as well. > > Original thread: >

Re: [HACKERS] PostmasterContext survives into parallel workers!?

On Mon, Aug 1, 2016 at 4:18 PM, Tom Lane wrote: > I noticed $subject while fooling around with the tqueue.c memory leak > issues. This does not seem like a good idea to me. At the very least, > it's a waste of space that could be used for something else, and at the > worst,

Re: [HACKERS] HandleParallelMessages contains CHECK_FOR_INTERRUPTS?

Alvaro Herrera writes: > Tom Lane wrote: >> $SUBJECT seems like a pretty bad idea, because it implies a recursive >> entry to ProcessInterrupts and thence to HandleParallelMessages itself. >> By what reasoning is that call necessary where it's placed? > I notice you

Re: [HACKERS] New version numbering practices

Andrew Dunstan writes: > Somewhat related is how we name the git branches. It would help me from > a buildfarm POV if we kept lexically them sortable, which could be done > at least for the next 90 major releases :-) by adding an underscore > after the REL piece, thus:

Re: [HACKERS] HandleParallelMessages contains CHECK_FOR_INTERRUPTS?

Tom Lane wrote: > $SUBJECT seems like a pretty bad idea, because it implies a recursive > entry to ProcessInterrupts and thence to HandleParallelMessages itself. > By what reasoning is that call necessary where it's placed? I notice you just removed the CHECK_FOR_INTERRUPTS in

[HACKERS] PostmasterContext survives into parallel workers!?

I noticed $subject while fooling around with the tqueue.c memory leak issues. This does not seem like a good idea to me. At the very least, it's a waste of space that could be used for something else, and at the worst, it might be a security issue because it leaves security-sensitive pg_hba and

Re: [HACKERS] New version numbering practices

On 08/01/2016 11:49 AM, Tom Lane wrote: Also, it strikes me that we need a new convention for how we talk about release branches informally. Up to now, mentioning say "9.5" without any further qualification in a PG-list message was usually sufficient to indicate a branch number, but I do not

Re: [HACKERS] New version numbering practices

David, * David Fetter (da...@fetter.org) wrote: > On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > "David G. Johnston" writes: > > > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly

Re: [HACKERS] New version numbering practices

On Mon, Aug 01, 2016 at 02:52:04PM -0400, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > "David G. Johnston" writes: > > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on > > > the lists. I suspect the choice will be

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

On 8/1/16 7:35 AM, Christoph Berg wrote: > PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces: > > # select pg_size_pretty((2^20)::bigint); > pg_size_pretty > > 1024 kB because it's "pretty" :) > SHOW does not: > > # show work_mem; > work_mem >

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On Mon, Aug 1, 2016 at 02:48:55PM -0400, Peter Eisentraut wrote: > On 7/30/16 2:16 PM, Bruce Momjian wrote: > > The second patch does what Tom suggests above by outputting only "KB", > > and it supports "kB" for backward compatibility. What it doesn't do is > > to allow arbitrary case, which I

Re: [HACKERS] New version numbering practices

* Tom Lane (t...@sss.pgh.pa.us) wrote: > "David G. Johnston" writes: > > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on > > the lists. I suspect the choice will be dependent on context and channel. > > Hmm, that seems like a workable answer

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On 7/30/16 1:18 AM, Pavel Stehule wrote: > We talked about this issue, when I wrote function pg_size_bytes. It is > hard to fix these functions after years of usage. The new set of > functions can be better > > pg_iso_size_pretty(); > pg_iso_size_bytes(); One thing that would actually be nice

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

On 7/30/16 2:16 PM, Bruce Momjian wrote: > The second patch does what Tom suggests above by outputting only "KB", > and it supports "kB" for backward compatibility. What it doesn't do is > to allow arbitrary case, which I think would be a step backward. The > second patch actually does match the

Re: [HACKERS] pg_basebackup wish list

On Thu, Jul 28, 2016 at 4:44 AM, Amit Kapila wrote: > On Tue, Jul 26, 2016 at 11:58 AM, Fujii Masao wrote: >> On Wed, Jul 13, 2016 at 3:06 AM, Jeff Janes wrote: >>> On Tue, Jul 12, 2016 at 10:48 AM, Peter Eisentraut >>>

[HACKERS] HandleParallelMessages contains CHECK_FOR_INTERRUPTS?

$SUBJECT seems like a pretty bad idea, because it implies a recursive entry to ProcessInterrupts and thence to HandleParallelMessages itself. By what reasoning is that call necessary where it's placed? regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] New version numbering practices

"David G. Johnston" writes: > I suspect I'll end up using 10.x somewhat frequently though I'm mostly on > the lists. I suspect the choice will be dependent on context and channel. Hmm, that seems like a workable answer as well, and one that's traceable to our past

Re: [HACKERS] New version numbering practices

On Mon, Aug 1, 2016 at 1:41 PM, Tom Lane wrote: > Over the past couple of months I have already found myself > writing "10.0" or "9.7^H^H^H10" to make it clear that I meant the next > release version, because just "10" seemed too ambiguous. ​I thought that was just (and

Re: [HACKERS] pg_replication_origin_xact_reset() and its argument variables

On Tue, Aug 2, 2016 at 2:48 AM, Andres Freund wrote: > Hi Fujii, > > On 2016-07-28 16:44:37 +0900, Fujii Masao wrote: >> On Sat, Jul 2, 2016 at 7:01 AM, Tom Lane wrote: >> > Andres Freund writes: >> >> On 2016-06-30 10:14:04 -0400, Tom

Re: [HACKERS] pg_replication_origin_xact_reset() and its argument variables

Hi Fujii, On 2016-07-28 16:44:37 +0900, Fujii Masao wrote: > On Sat, Jul 2, 2016 at 7:01 AM, Tom Lane wrote: > > Andres Freund writes: > >> On 2016-06-30 10:14:04 -0400, Tom Lane wrote: > >>> Fujii Masao writes: > As far as I

Re: [HACKERS] pg_replication_origin_xact_reset() and its argument variables

On 2016-07-28 16:44:37 +0900, Fujii Masao wrote: > diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml > index d6ed0ce..0a3d3de 100644 > --- a/doc/src/sgml/func.sgml > +++ b/doc/src/sgml/func.sgml > @@ -17519,7 +17519,7 @@ postgres=# SELECT * FROM >

Re: [HACKERS] New version numbering practices

David Fetter writes: > On Mon, Aug 01, 2016 at 11:49:41AM -0400, Tom Lane wrote: >> Also, it strikes me that we need a new convention for how we talk about >> release branches informally. Up to now, mentioning say "9.5" without >> any further qualification in a PG-list message

Re: [HACKERS] Constraint merge and not valid status

Robert Haas writes: > Well, on second thought, I'm no longer sure that this approach makes > sense. I mean, it's obviously wrong for constraint-merging to change > the validity marking on a constraint, but that does not necessarily > imply that we shouldn't merge the

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Tomas Vondra writes: > What is needed is an overview of the approach, so that the reviewers can > read that first, instead of assembling the knowledge from pieces > scattered over comments in many pieces. But I see the fasttab.c contains > this: > /* TODO TODO

Re: [HACKERS] Any need of GRANT/REVOKE CREATE TABLE | POLICY | ETC

On Tue, Jul 19, 2016 at 2:59 AM, Haribabu Kommi wrote: > During the discussion of supporting multi tenancy with the help of > row level security, because of some problems of executing any > policy that was created by an unprivileged user [1]. > > To avoid that problem,

Re: [HACKERS] New version numbering practices

Tom Lane wrote: > Also, it strikes me that we need a new convention for how we talk about > release branches informally. Up to now, mentioning say "9.5" without > any further qualification in a PG-list message was usually sufficient > to indicate a branch number, but I do not think that will

Re: [HACKERS] PostgreSQL 10 kick-off

Simon Riggs writes: > Can we confirm/refute these details now to make sure we are all in tune? See the other thread I started about that; please reserve this thread for discussions of general actions around starting the new development cycle.

[HACKERS] TODO item: Implement Boyer-Moore searching in LIKE queries

Hi pgsql-hackers, Following the patch to implement strpos with Boyer-Moore-Horspool, it was proposed we bring BMH to LIKE as well. Original thread: https://www.postgresql.org/message-id/flat/27645.1220635769%40sss.pgh.pa.us#27645.1220635...@sss.pgh.pa.us I'm a first time hacker and I found this

Re: [HACKERS] New version numbering practices

On Mon, Aug 01, 2016 at 11:49:41AM -0400, Tom Lane wrote: > As Peter mentioned in > https://www.postgresql.org/message-id/ba76aeb0-2f84-d180-268f-ea0f5ace4...@2ndquadrant.com > the decision has been taken to simplify our user-facing version numbering > system to be a two-component number. Since

Re: [HACKERS] Constraint merge and not valid status

On Fri, Jul 22, 2016 at 1:10 AM, Amit Langote wrote: > On 2016/07/22 0:38, Robert Haas wrote: >> On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote >> wrote: >>> Consider a scenario where one adds a *valid* constraint on a inheritance >>>

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Tue, Jul 26, 2016 at 9:44 PM, Michael Paquier wrote: > On Wed, Jul 27, 2016 at 12:41 AM, John Harvey > wrote: >> Because of this, I've submitted a small patch which fixes the verbosity of >> the error message to actually explain what's

Re: [HACKERS] PostgreSQL 10 kick-off

On Mon, Aug 1, 2016 at 12:25 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > - We need a commit fest manager. Volunteers, step forward! > What knowledge is expected for a CFM? I'm really would like to help and also learn more about our development. Regards, -- Fabrízio de

Re: [HACKERS] pg_replication_origin_xact_reset() and its argument variables

On Thu, Jul 28, 2016 at 3:44 AM, Fujii Masao wrote: Sure looks that way from here. Copy-and-paste from the previous line in pg_proc.h, perhaps? >> >>> Yes, that's clearly wrong. > > Attached patch (pg_replication_origin_xact_reset_9.6.patch) fixes this. > We need

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 09:49:33AM -0400, Tom Lane wrote: > David Fetter writes: > > Please find attached a patch which makes it possible to disallow > > UPDATEs and DELETEs which lack a WHERE clause. As this changes query > > behavior, I've made the new GUCs PGC_SUSET. > > >

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

On Mon, Aug 1, 2016 at 01:35:53PM +0200, Christoph Berg wrote: > Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@momjian.us> > > I also just applied a doc patch that increases case and spacing > > consistency in the use of kB/MB/GB/TB. > > Hi, > > PostgreSQL uses the spaces inconsistently,

Re: [HACKERS] PostgreSQL 10 kick-off

On 1 August 2016 at 17:04, Tom Lane wrote: > Simon Riggs writes: >> Can we confirm/refute these details now to make sure we are all in tune? > > See the other thread I started about that; please reserve this thread > for discussions of general actions

Re: [HACKERS] PostgreSQL 10 kick-off

On 1 August 2016 at 16:25, Peter Eisentraut wrote: > - The next major release of PostgreSQL (after 9.6) will be known as > PostgreSQL 10. (The actual version number of the first production > release will as before have a minor version number of .0, so the

[HACKERS] New version numbering practices

As Peter mentioned in https://www.postgresql.org/message-id/ba76aeb0-2f84-d180-268f-ea0f5ace4...@2ndquadrant.com the decision has been taken to simplify our user-facing version numbering system to be a two-component number. Since there have been questions about the details of that, I wanted to

Re: [HACKERS] Combining hash values

Dean Rasheed writes: > On that subject, while looking at hashfunc.c, I spotted that > hashint8() has a very obvious deficiency, which causes disastrous > performance with certain inputs: Well, if you're trying to squeeze 64 bits into a 32-bit result, there are always

[HACKERS] PostgreSQL 10 kick-off

A few notes on the next PostgreSQL development cycle (the one after 9.6): - After several rounds of consultations, it has been decided to change the version numbering scheme. Instead of X.Y.Z, future releases will have a two-part version number M.N, where M is the major version number, which

Re: [HACKERS] Combining hash values

Greg Stark writes: > I was originally going to suggest using a crc to combine but iirc we > changed hash_any() a while back and decided against using crc. I don't know > if that was wise but wouldn't want to suggest relitigating that. Nah, CRCs are designed to solve a different

Re: [HACKERS] Broken order-of-operations in parallel query latch manipulation

Amit Kapila writes: > On Mon, Aug 1, 2016 at 1:58 AM, Tom Lane wrote: >> I believe this is wrong and the CHECK_FOR_INTERRUPTS needs to be before >> or after the two latch operations. As-is, if the reason somebody set >> our latch was to get us to

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Robbie, all, * Robbie Harwood (rharw...@redhat.com) wrote: > Michael Paquier writes: > > On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood > > wrote: > >> Michael Paquier writes: > >> > >> So there's a connection

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On Mon, Aug 1, 2016 at 10:19 AM, Tom Lane wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Building on the has-property approach Andrew suggested, I wonder if > >> we need something like pg_index_column_has_property(indexoid,

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Building on the has-property approach Andrew suggested, I wonder if > >> we need something like pg_index_column_has_property(indexoid, colno, > >> propertyname) with

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Building on the has-property approach Andrew suggested, I wonder if >> we need something like pg_index_column_has_property(indexoid, colno, >> propertyname) with properties like "sortable", "desc", "nulls

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Yeah. I'm not very impressed by the underlying assumption that it's > >> okay for client-side code to hard-wire knowledge about what indoption > >> bits mean,

Re: [HACKERS] Why we lost Uber as a user

Stephen Frost writes: > * Hannu Krosing (hkros...@gmail.com) wrote: >> Is there any theoretical obstacle which would make it impossible to >> teach VACUUM not to hold back the whole vacuum horizon, but just >> to leave a single transaction alone in case of a long-running >>

Re: [HACKERS] Why we lost Uber as a user

* Hannu Krosing (hkros...@gmail.com) wrote: > On 07/27/2016 12:07 AM, Tom Lane wrote: > > > >> 4. Now, update that small table 500 times per second. > >> That's a recipe for runaway table bloat; VACUUM can't do much because > >> there's always some minutes-old transaction hanging around (and

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

> -Original Message- > From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp] > Sent: Monday, August 01, 2016 8:26 PM > To: Ashutosh Bapat > Cc: Kaigai Kouhei(海外 浩平); pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown > plans > > On

Re: [HACKERS] Why we lost Uber as a user

On 07/27/2016 12:07 AM, Tom Lane wrote: > >> 4. Now, update that small table 500 times per second. >> That's a recipe for runaway table bloat; VACUUM can't do much because >> there's always some minutes-old transaction hanging around (and SNAPSHOT >> TOO OLD doesn't really help, we're talking

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/01/2016 11:45 AM, Aleksander Alekseev wrote: Hello. Thanks everyone for great comments! Well, jokes aside, that's a pretty lousy excuse for not writing any docs I think maybe I put it in a wrong way. There are currently a lot of comments in a code, more then enough to understand how

[HACKERS] Confusing docs about GetForeignUpperPaths in fdwhandler.sgml

Hi, I noticed that the following note about direct modification via GetForeignUpperPaths in fdwhandler.sgml is a bit confusing. We have another approach using PlanDirectModify, so that should be reflected in the note as well. Please find attached a patch. PlanForeignModify and the

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/08/01 20:31, Ashutosh Bapat wrote: I thought about the Relations line a bit more and noticed that there are cases where the table reference names for joining relations in the Relations line are printed incorrectly. Here is an example: postgres=# explain verbose select *

[HACKERS] pg_size_pretty, SHOW, and spaces

Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@momjian.us> > I also just applied a doc patch that increases case and spacing > consistency in the use of kB/MB/GB/TB. Hi, PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces: # select pg_size_pretty((2^20)::bigint);

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

> I thought about the Relations line a bit more and noticed that there are > cases where the table reference names for joining relations in the > Relations line are printed incorrectly. Here is an example: > > postgres=# explain verbose select * from (select t1.a, t2.a from ft1 t1, > ft2 t2 where

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/07/29 13:28, Ashutosh Bapat wrote: I wrote: Probably something like this: Foreign Processing Remote Operations: ... In the Remote Operations line, the FDW/extension could print any info about remote

Re: [HACKERS] Combining hash values

On 1 August 2016 at 08:19, Greg Stark wrote: > Surely combining multiple hashes is the same problem as hashing a block of > memory? Shouldn't we just use the same algorithm as hash_any()? > Yes, I imagine that should work well. I suspect that Thomas's proposal would also probably

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/07/29 13:05, Etsuro Fujita wrote: In a foreign-join case, however, we can't see such relations from the EXPLAIN printed *by core*. postgres_fdw avoids this issue by adding such relations to the EXPLAIN using ExplainForeignScan as shown in the below example, but since such relations are

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Hello. Thanks everyone for great comments! > Well, jokes aside, that's a pretty lousy excuse for not writing any > docs I think maybe I put it in a wrong way. There are currently a lot of comments in a code, more then enough to understand how this feature works. What I meant is that this is

Re: [HACKERS] pg_basebackup wish list

On Fri, Jul 29, 2016 at 11:01 PM, Amit Kapila wrote: > On Thu, Jul 28, 2016 at 7:34 PM, Fujii Masao wrote: >> On Thu, Jul 28, 2016 at 10:16 PM, Amit Kapila >> wrote: >> >>> I think there is some value in providing >>>

Re: [HACKERS] Changed SRF in targetlist handling

On 2016-05-25 16:55:23 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-05-25 15:20:03 -0400, Tom Lane wrote: > >> We could certainly make a variant behavior in nodeFunctionscan.c that > >> emulates that, if we feel that being exactly bug-compatible on the point > >>

Re: [HACKERS] Slowness of extended protocol

Greg wrote: > I think you're looking at this the wrong way around. 30% of what? > You're doing these simple read-only selects on a database that > obviously is entirely in RAM. If you do the math on the numbers you > gave above the simple protocol took 678 microseconds per transaction > and the

Re: [HACKERS] Combining hash values

Surely combining multiple hashes is the same problem as hashing a block of memory? Shouldn't we just use the same algorithm as hash_any()? I was originally going to suggest using a crc to combine but iirc we changed hash_any() a while back and decided against using crc. I don't know if that was

Re: [HACKERS] Syntax of xmltable function

2016-07-31 17:53 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > The SQL/XML syntax is: > > > XMLTABLE ( > > xmlquery > > PASSING xmldocument > > [COLUMNS columns_list] ) > > > columns_list := column_list ',' colname > > > colname := colname

Re: [HACKERS] System load consideration before spawning parallel workers

On 01/08/16 18:08, Haribabu Kommi wrote: On Fri, Jul 29, 2016 at 8:48 PM, Amit Kapila wrote: On Fri, Jul 29, 2016 at 11:26 AM, Haribabu Kommi wrote: we observed that spawning the specified number of parallel workers for every query that

Re: [HACKERS] System load consideration before spawning parallel workers

On Fri, Jul 29, 2016 at 8:48 PM, Amit Kapila wrote: > On Fri, Jul 29, 2016 at 11:26 AM, Haribabu Kommi > wrote: >> we observed that spawning the specified number of parallel workers for >> every query that satisfies for parallelism is sometimes