On Thu, Jun 2, 2016 at 1:00 PM, Michael Paquier
wrote:
> I have added an open item for 9.6 regarding this patch, that would be
> good to complete this work in this release for consistency with the
> other objects.
Doh. I forgot to update psql --help.
--
Michael
From 9901595fd000c3ac9e1c1ce8ee2f2
On Thu, Jun 2, 2016 at 12:25 PM, Thomas Munro
wrote:
> This patch allows identifiers to be specified by the WaitLatch and
> WaitLatchOrSocket calls, but not for WaitEventSetWait, which is the
> more general waiting primitive. I think it should be done by
> WaitEventSetWait, and merely passed down
On Wed, Jun 1, 2016 at 8:25 PM, Teodor Sigaev wrote:
As far as I can see, COMMENT ON has no support for access methods.
Wouldn't we want to add it as it is created by a command? On top of
that, perhaps we could have a backslash command in psql to list the
supported access metho
On Fri, May 20, 2016 at 8:14 AM, Michael Paquier
wrote:
> Hi all,
>
> As I mentioned $subject a couple of months back after looking at the
> wait event facility here:
> http://www.postgresql.org/message-id/CAB7nPqTJpgAvOK4qSC96Fpm5W+aCtJ9D=3Vn9AfiEYsur=-j...@mail.gmail.com
> I have actually taken
On Thu, May 26, 2016 at 03:27:40PM +0530, Amit Kapila wrote:
> I think the workers should stop processing tuples after the tuple queues
> got detached. This will not only handle above situation gracefully, but
> will allow to speed up the queries where Limit clause is present on top of
> Gather no
On Thu, May 26, 2016 at 05:08:31PM +0530, Amit Kapila wrote:
> Just to summarize, apart from above issue, we have discussed two different
> issues related to parallel query in this thread.
> a. Push down of parallel restricted clauses to nodes below gather. Patch
> to fix same is posted upthread [
On Sun, May 29, 2016 at 01:36:01AM -0400, Noah Misch wrote:
> On Fri, May 06, 2016 at 03:06:01PM -0400, Robert Haas wrote:
> > On Thu, May 5, 2016 at 10:48 AM, David Rowley
> > wrote:
> > > On 5 May 2016 at 16:04, David Rowley wrote:
> > >> I've started making some improvements to this, but need
On 2016-06-01 15:33:18 -0700, Andres Freund wrote:
> Cpu: i7-6820HQ
> Ram: 24GB of memory
> Storage: Samsung SSD 850 PRO 1TB, encrypted
> postgres -c shared_buffers=6GB -c backend_flush_after=128 -c
> max_wal_size=100GB -c fsync=on -c synchronous_commit=off
> pgbench -M prepared -c 16 -j 16 -T 520
> -Original Message-
> From: Jim Nasby [mailto:jim.na...@bluetreble.com]
> Sent: Wednesday, June 01, 2016 11:32 PM
> To: Kaigai Kouhei(海外 浩平); Gavin Flower; Joe Conway; Ants Aasma; Simon Riggs
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Does people favor to have matrix data
On 06/02/2016 01:41 AM, Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 7:36 AM, Andreas Karlsson
wrote:
>> Looked at this quickly and I do not think adding it would be what I
consider
>> a small patch since we would essentially need to copy the validation
logic
>> from DefineAggregate and Ag
On Thu, Jun 2, 2016 at 7:36 AM, Andreas Karlsson wrote:
> On 05/25/2016 03:32 AM, Tom Lane wrote:
>>
>> Andreas Karlsson writes:
>>>
>>> On 05/25/2016 02:41 AM, Robert Haas wrote:
I'd rather extend see us ALTER AGGREGATE to do this.
>>
>>
>>> Wouldn't that prevent this from going into 9
On Thu, Jun 2, 2016 at 6:40 AM, Tom Lane wrote:
> I suggest that there's a more principled reason for refusing a back-patch
> here, which is that we don't back-patch new features, only bug fixes.
> This request is certainly not a bug fix. It's in support of a new feature
> --- and one that's not
On 05/25/2016 03:32 AM, Tom Lane wrote:
Andreas Karlsson writes:
On 05/25/2016 02:41 AM, Robert Haas wrote:
I'd rather extend see us ALTER AGGREGATE to do this.
Wouldn't that prevent this from going into 9.6? I do not think changing
ALTER AGGREGATE is 9.6 materials.
Well, it's debatable -
On 2016-05-31 16:03:46 -0400, Robert Haas wrote:
> On Fri, May 27, 2016 at 12:37 AM, Andres Freund wrote:
> > I don't think the situation is quite that simple. By *disabling* backend
> > flushing it's also easy to see massive performance regressions. In
> > situations where shared buffers was c
On Wed, Jun 1, 2016 at 5:40 PM, Tom Lane wrote:
> > On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas
> wrote:
> >> Probably not, but yes, I do want to reduce the commit load. I also
> >> think that we essentially have a contract with our users to limit what
> >> we back-patch to critical bug fixes an
> On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas wrote:
>> Probably not, but yes, I do want to reduce the commit load. I also
>> think that we essentially have a contract with our users to limit what
>> we back-patch to critical bug fixes and security fixes. When we don't
>> do that, people start as
On 06/01/2016 02:21 PM, Robert Haas wrote:
> If you lined up ten people in a room all of whom were competent
> database professionals and none of whom knew anything about PostgreSQL
> and asked them to guess what a setting called work_mem does and what a
> setting called max_parallel_degree does, I
Robert Haas writes:
> I've largely given up hope of coming up with an alternative that can
> attract more than one vote and that is also at least mildly accurate,
> but one idea is max_parallel_workers_per_gather_node. That will be
> totally clear.
Given the reference to Gather nodes, couldn't y
On Wed, Jun 1, 2016 at 5:04 PM, Robert Haas wrote:
> On Wed, Jun 1, 2016 at 12:24 PM, Alvaro Herrera
> wrote:
> > Robert Haas wrote:
> >> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer
> wrote:
> >> > On 1 June 2016 at 11:48, Michael Paquier
> wrote:
> >> >> Could it be possible to mark Postmas
On Wed, Jun 1, 2016 at 10:10 AM, Tom Lane wrote:
> Amit Kapila writes:
>> Your explanation is clear, however the name max_parallel_workers makes it
>> sound like that parallelising an operation is all about workers. Yes it
>> depends a lot on the number of workers allocated for parallel operatio
Hi
Following along with a btree bug report, I saw a typo "referencd" in a
comment. Also "we've" seems a bit odd here, but maybe it's just me.
Maybe it should be like this?
--- a/src/include/access/nbtree.h
+++ b/src/include/access/nbtree.h
@@ -522,7 +522,7 @@ typedef struct BTScanPosData
On Wed, Jun 1, 2016 at 12:24 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer wrote:
>> > On 1 June 2016 at 11:48, Michael Paquier wrote:
>> >> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
>> >> and back-branches?
>> >
>> > So
Paul Ramsey writes:
> One of the things people find annoying about postgis is that
> ST_Intersects(ST_Intersection(a, b), a) can come out as false (a
> derived point at a crossing of lines may not exactly intersect either
> of the input lines), which is a direct result of our use of exact math
> f
2016-06-01 17:55 GMT+02:00 Jim Nasby :
> On 5/31/16 7:04 PM, Peter van Hardenberg wrote:
>
>> The idea of converting a JSONB array to a PG array is appealing and
>> would potentially be more general-purpose than adding a new unnest. I'm
>> not sure how feasible either suggestion is.
>>
>
> The one
I wrote:
> I am pretty strongly tempted to get rid of MasterStartParallelItem
> altogether and just hard-code what it does in DispatchJobForTocEntry.
> ...
> A different line of thought would be to fix the worker-command-parsing
> situation by allowing the parsing to happen in format-specific code,
On Wed, Jun 1, 2016 at 8:59 AM, Jim Nasby wrote:
> On 6/1/16 10:03 AM, Paul Ramsey wrote:
>>
>> We don't depend on these, we have our own :/
>> The real answer for a GIS system is to have an explicit tolerance
>> parameter for calculations like distance/touching/containment, but
>> unfortunately w
On Tue, May 31, 2016 at 06:15:32PM -0400, David G. Johnston wrote:
> I stand corrected. I was thinking you could somehow craft unnest(' value here>') but there is no way to auto-convert to "anyarray"...
>
> > The json_array_elements family manages to do the right thing. Why
> > would it be harde
Robert Haas wrote:
> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer wrote:
> > On 1 June 2016 at 11:48, Michael Paquier wrote:
> >> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
> >> and back-branches?
> >
> > Sounds sensible to me.
>
> I don't really want to set a precedent
On Tue, May 31, 2016 at 6:20 PM, Tom Lane wrote:
> David Fetter writes:
> > On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote:
> >> While likely not that common the introduction of an ambiguity makes
> >> raises the bar considerably.
>
> > What ambiguity?
>
> You get that as a re
On Wed, Jun 1, 2016 at 11:55 AM, Jim Nasby wrote:
> On 5/31/16 7:04 PM, Peter van Hardenberg wrote:
>
>> The idea of converting a JSONB array to a PG array is appealing and
>> would potentially be more general-purpose than adding a new unnest. I'm
>> not sure how feasible either suggestion is.
>>
On 06/01/2016 05:15 PM, Tom Lane wrote:
Andreas Karlsson writes:
On 06/01/2016 04:44 PM, Tom Lane wrote:
I don't understand why you think you need the CREATE OR REPLACE FUNCTION
commands? We only need to change proargtypes, and the updates did that.
The catcache can take care of itself.
Ma
On 6/1/16 10:03 AM, Paul Ramsey wrote:
We don't depend on these, we have our own :/
The real answer for a GIS system is to have an explicit tolerance
parameter for calculations like distance/touching/containment, but
unfortunately we didn't do that so now we have our own
compatibility/boil the oc
On 5/31/16 7:04 PM, Peter van Hardenberg wrote:
The idea of converting a JSONB array to a PG array is appealing and
would potentially be more general-purpose than adding a new unnest. I'm
not sure how feasible either suggestion is.
The one part I think is missing right now is unnest allows you
On Wed, Jun 1, 2016 at 11:45 AM, Petr Jelinek wrote:
> That GUC also controls worker processes that are started by extensions,
> not just ones that parallel query starts. This is btw one thing I don't
> like at all about how the current limits work, the parallel query will
> fight for workers wit
On 01/06/16 17:27, Jim Nasby wrote:
On 5/31/16 8:48 PM, Robert Haas wrote:
On Tue, May 31, 2016 at 5:58 PM, Tom Lane wrote:
Alvaro Herrera writes:
Robert Haas wrote:
I just want to point out that if we change #1, we're breaking
postgresql.conf compatibility for, IMHO, not a whole lot of ben
On 5/31/16 8:48 PM, Robert Haas wrote:
On Tue, May 31, 2016 at 5:58 PM, Tom Lane wrote:
Alvaro Herrera writes:
Robert Haas wrote:
I just want to point out that if we change #1, we're breaking
postgresql.conf compatibility for, IMHO, not a whole lot of benefit.
I'd just leave it alone.
We
Andreas Karlsson writes:
> On 06/01/2016 04:44 PM, Tom Lane wrote:
>> I don't understand why you think you need the CREATE OR REPLACE FUNCTION
>> commands? We only need to change proargtypes, and the updates did that.
>> The catcache can take care of itself.
> Maybe I did something wrong (I try
On 06/01/2016 07:52 AM, Jim Nasby wrote:
> On 6/1/16 9:27 AM, Tom Lane wrote:
>> Kevin Grittner writes:
>>> > On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas
>>> wrote:
>> Figuring out what to do about it is harder. Your proposal seems
to be
>> to remove them except where we need the
On Wed, Jun 1, 2016 at 7:52 AM, Jim Nasby wrote:
>
> I suspect another wrinkle here is that in the GIS world a single point can
> be represented it multiple reference/coordinate systems, and it would have
> different values in each of them. AIUI the transforms between those systems
> can be rathe
On Tue, May 31, 2016 at 06:20:26PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Tue, May 31, 2016 at 05:06:00PM -0400, David G. Johnston wrote:
> >> While likely not that common the introduction of an ambiguity makes
> >> raises the bar considerably.
>
> > What ambiguity?
>
> My first th
On 06/01/2016 04:44 PM, Tom Lane wrote:
Andreas Karlsson writes:
It is the least ugly of all the ugly solutions I could think of. I have
attached a patch which fixes the signatures using this method. I use
CREATE OR REPLACE FUNCTION to update to catcache. What do you think? Is
it too ugly?
I
While testing parallel dump/restore over the past few days, I noticed that
it seemed to do an awful lot of duplicative SET commands, which I traced
to the fact that restore was doing _doSetFixedOutputState(AH) in the wrong
place, ie, once per TOC entry not once per worker. Another thing that's
use
On 6/1/16 9:27 AM, Tom Lane wrote:
Kevin Grittner writes:
> On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas wrote:
>> Figuring out what to do about it is harder. Your proposal seems to be
>> to remove them except where we need the fuzzy behavior, which doesn't
>> sound unreasonable, but I don't
Andreas Karlsson writes:
> It is the least ugly of all the ugly solutions I could think of. I have
> attached a patch which fixes the signatures using this method. I use
> CREATE OR REPLACE FUNCTION to update to catcache. What do you think? Is
> it too ugly?
I don't understand why you think yo
On 5/30/16 9:05 PM, Kouhei Kaigai wrote:
Due to performance reason, location of each element must be deterministic
without walking on the data structure. This approach guarantees we can
reach individual element with 2 steps.
Agreed.
On various other points...
Yes, please keep the discussion h
Kevin Grittner writes:
> On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas wrote:
>> Figuring out what to do about it is harder. Your proposal seems to be
>> to remove them except where we need the fuzzy behavior, which doesn't
>> sound unreasonable, but I don't personally understand why we need it
>>
On Wed, Jun 1, 2016 at 8:08 AM, Robert Haas wrote:
> On Fri, May 27, 2016 at 6:43 AM, Emre Hasegeli wrote:
>> There are those macros defined for the built-in geometric types:
>>
>>> #define EPSILON 1.0E-06
>>
>>> #define FPzero(A) (fabs(A) <= EPSILON)
>>> #define FPe
Amit Kapila writes:
> Your explanation is clear, however the name max_parallel_workers makes it
> sound like that parallelising an operation is all about workers. Yes it
> depends a lot on the number of workers allocated for parallel operation,
> but that is not everything. I think calling it ma
> However, the problem I pointed out is that when the new library is
> incompatible with the older one, say the major version of libpq.dll
> changes from 5 to 6, the application user and/or developer cannot
> notice the incompatibility immediately and easily. On Unix/Linux,
> the application fails
On 1 June 2016 at 14:20, Konstantin Knizhnik
wrote:
> I wonder why domain types can not be used for specification of array
> element:
>
> create domain objref as bigint;
> create table foo(x objref[]);
> ERROR: type "objref[]" does not exist
> create table foo(x bigint[]);
> CREATE TABLE
>
> Is
I wonder why domain types can not be used for specification of array
element:
create domain objref as bigint;
create table foo(x objref[]);
ERROR: type "objref[]" does not exist
create table foo(x bigint[]);
CREATE TABLE
Is there some principle problem here or it is just not implemented?
--
K
On Wed, Jun 1, 2016 at 9:00 AM, Robert Haas wrote:
> On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer
> wrote:
> > On 1 June 2016 at 11:48, Michael Paquier
> wrote:
> >> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
> >> and back-branches?
> >
> > Sounds sensible to me.
>
>
On Fri, May 27, 2016 at 6:43 AM, Emre Hasegeli wrote:
> There are those macros defined for the built-in geometric types:
>
>> #define EPSILON 1.0E-06
>
>> #define FPzero(A) (fabs(A) <= EPSILON)
>> #define FPeq(A,B) (fabs((A) - (B)) <= EPSILON)
>> #define
On Wed, Jun 1, 2016 at 12:06 AM, Craig Ringer wrote:
> On 1 June 2016 at 11:48, Michael Paquier wrote:
>> Could it be possible to mark PostmasterPid with PGDLLIMPORT on HEAD
>> and back-branches?
>
> Sounds sensible to me.
I don't really want to set a precedent that we'll back-patch
PGDLLIMPORT
On Wed, Jun 1, 2016 at 9:49 AM, Michael Paquier
wrote:
> On Wed, Jun 1, 2016 at 3:56 AM, David G. Johnston
> wrote:
>> On Tue, May 31, 2016 at 2:19 PM, Peter Eisentraut
>> wrote:
>>>
>>> On 5/31/16 1:47 PM, Jaime Casanova wrote:
Are we going to change synchronous_standby_names? Certain
As far as I can see, COMMENT ON has no support for access methods.
Wouldn't we want to add it as it is created by a command? On top of
that, perhaps we could have a backslash command in psql to list the
supported access methods, like \dam[S]? The system methods would be in
this case all the in-cor
On Tue, May 31, 2016 at 11:30 PM, Tom Lane wrote:
>
> I wrote:
> > I really think that a GUC named "max_parallel_workers", which in fact
> > limits the number of workers and not something else, is the way to go.
>
> To be concrete, I suggest comparing the attached documentation patch
> with Robert
On 2016/06/01 13:07, sri harsha wrote:
> Hi,
>
> In PostgreSQL , does the order in which the criteria is given matter ??
> For example
>
> Query 1 : Select * from TABLE where a > 5 and b < 10;
>
> Query 2 : Select * from TABLE where b <10 and a > 5;
>
> Are query 1 and query 2 the same in P
On Sat, May 7, 2016 at 5:34 AM, Robert Haas wrote:
> On Mon, May 2, 2016 at 8:25 PM, Andres Freund wrote:
>> + * heap_tuple_needs_eventual_freeze
>> + *
>> + * Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
>> + * will eventually require freezing. Similar to heap_tuple_
59 matches
Mail list logo
