> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Tuesday, August 02, 2016 2:45 PM
> To: Kaigai Kouhei(海外 浩平); Ashutosh Bapat
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown
> plans
>
> On
On Tue, Aug 2, 2016 at 10:28 AM, Michael Paquier
wrote:
> There is still an issue with pg_basebackup when testing stream mode
> and replication slots. I am digging into this one now..
After 5 hours running this test in a row and 30 attempts torturing
hamster with a script running make check in an
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
>
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 opera
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. busy in checking visibi
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 the names
> > of socket_* functions should be accompan
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
@@ -66
> 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
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 refactoring it again will create
> > back-patch hazards.
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
Processing",
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
> +InitToastSnapshot(Snapshot snapshot, XLogRecPtr lsn)
> +{
> + snapshot->satisf
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 (pgsql-hackers@postgresql.org)
To m
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 wonder if that could bite postmaster.
>
> I seriously d
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 not find you.
--
Michae
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 mistake. We had better use
>>> replay_location instead of write_location. There is
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
> >> at least for the next 90 major release
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 bring BMH to LIKE as well.
> >
> > Original thre
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 about the postmaster is that
it run
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 major releases :-) by adding an underscore
>>
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
> >>> that bgworkers aren't launched from
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 handler? Blech.)
>
>> Isn't pretty much ev
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 setting latch, which
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.)
>
> > Isn't pretty much e
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 on-demand below post
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 terms of the benefits we get.
>> I've thought fo
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 started from a
> sign
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 imagine that should work well. I suspect t
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, if you're trying to squeeze 64 bits into a 32-
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 l
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 work in signal handlers
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 pgsq
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:
> https://www.postgresql.org/message-id/flat/27645.1220635769%40sss.pgh.pa.us#27645.1220635...@sss.pgh.pa.us
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, it might be a securit
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 just removed the CHECK_FOR_INT
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: REL_10_STABLE. I realise
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
HandleParallelMessag
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 p
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
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
> > > > on
> > > > the list
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 dependent on context and channel.
>
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
> ───
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 th
* 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 as well, and one that's trac
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 for
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
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
>>> wrote:
On 7/12/16 12:53 PM, Jeff Janes wrote:
> The --help message
$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 (pgsql-hacke
"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 habits.
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 maybe some instances wer
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 Lane wrote:
>> >>> Fujii Masao writes:
>> As far as I
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 read the code of the function, those arguments don't seem to
> >
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
> pg_xlogfile_name_offset(pg_stop_backup(
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 was usually suffici
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 constraints, does it? I see
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 comment the general idea - in-mem
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, If we have some kind of new
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 work
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.
regards, tom lane
--
Sent
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
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 th
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
>>> parent which is then merged with a child table's *not valid* co
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 missing. I hope that this
>> patch will be considered for
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 Ro
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 to apply this at least
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.
>
> > What say?
>
> -1.
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,
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 around starting the new development
> cycle.
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 actual
> release number will be 10.0.)
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 emp
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 going to be collisions somewh
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 chan
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 problem, ie detec
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 notice that a CHECK_FOR_INTERRUPTS condition
>> h
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 setting `sslmode` that we'll want something
> >> similar to here (`gssapimode` or
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, colno,
> >> propertyname) with propertie
* 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 properties like "sort
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 first".
> Right, this make
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, but not okay for it t
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
>> REPEATABLE READ transac
* 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 SNAPSH
> -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
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 about
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 th
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
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 *
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);
> 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
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 operati
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 work well, as wo
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 e
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 not
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
>>> .tar for -Z 0,
>>
>> I was thinking that "-Ft -Z0" is something like an alias
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
> >> is actually what we
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 ext
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 w
95 matches
Mail list logo
