On Thu, Jul 14, 2016 at 02:00:59AM +0200, Andreas Karlsson wrote:
> On 07/09/2016 05:42 AM, David Rowley wrote:
> >On 30 June 2016 at 03:49, Robert Haas wrote:
> >>On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson wrote:
> >>>On 06/24/2016 01:31 PM, David Rowley wrote:
> Seems there's a small
On Sat, Jul 23, 2016 at 01:40:01PM +0900, Michael Paquier wrote:
> On Fri, Jul 22, 2016 at 6:27 PM, Philippe BEAUDOIN wrote:
> > I am currently playing with extensions. And I found a strange behaviour
> > change with 9.6beta2 and 3 when pg_dumping a database with an extension
> > having sequences.
On 25.07.2016 19:53, Peter Eisentraut wrote:
I was trying to look up the background of this error message:
"Ispell dictionary supports only \"default\", \"long\", and \"num\" flag
value"
(src/backend/tsearch/spell.c)
But I found that this actually talks about Hunspell format dictionaries.
(So
On 21/07 08.42, Jeff Janes wrote:
> In Danish, the sequence 'aa' is sometimes treated as a single letter
> which collates after 'z'.
For the record: this is also true for Norwegian, in both locales it
collates equal to 'Ã¥' which is the 29th letter of the alphabet. But
'aa' is no longer used in or
>Can you please patch BRIN to use this new function too?
On my machine replacement of both BRIN update cases (see
https://github.com/x4m/pggistopt/commit/a6d301ff79104b977619339d53aebf748045418a
) showed no performance changes on folowing update query (6 seconds of
updates avg):
create table dataT
And a doc patch to go with it:
--
Andrew (irc:RhodiumToad)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 0689cc9..3e13e38 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -577,6 +577,89 @@
+
+Capability information formerly
On Tue, Jul 26, 2016 at 4:50 PM, Noah Misch wrote:
> [Action required within 72 hours. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 9.6 open item. Stephen,
> since you committed the patch believed to have created it, you own this open
> item. If some
On 26/07/16 00:05, Hannu Krosing wrote:
CREATE PUBLICATION mypub;
ALTER PUBLICATION mypub ADD TABLE users, departments;
Would a subscription just be a logical grouping or would it be something
stronger
like meaning atomic subscriptions and/or a dedicated replication slot ?
Not sure what you
On Mon, Jul 25, 2016 at 9:53 PM, Michael Paquier
wrote:
> On Mon, Jul 25, 2016 at 7:42 PM, Ildar Musin wrote:
>> I was checking out TAP tests documentation. And I found confusing this part
>> of src/test/perl/README file:
>>
>> my $ret = $node->psql('postgres', 'SELECT 1');
>> is($ret, '1
Hi!
I like the idea and implementation, but I have one suggestion.
> Instead of propagating carry after each new value, it's done only every
> values (or at the end).
I think we could do carry every 0x7FF / 1 accumulation, couldn't we?
Best regards, Andrey Borodin, Octonica & Ural
On Tue, Jul 26, 2016 at 9:02 AM, Chapman Flack wrote:
> On 07/25/16 22:09, Michael Paquier wrote:
>
>> This is over-complicating things for little gain. The new behavior of
>> filling in with zeros the tail of a segment makes things far better
>> when using gzip in archive_command.
>
> Then how ab
On Mon, Jul 25, 2016 at 8:28 PM, Peter Eisentraut
wrote:
> On 7/22/16 7:01 PM, Andrew Gierth wrote:
>> In light of the fact that it is an endless cause of bugs both in pg and
>> potentially to applications, I propose that we cease attempting to
>> conform to the spec's definition of IS NULL in fav
On 07/26/2016 08:48 AM, Amit Kapila wrote:
> general, if you have a very low WAL activity, then the final size of
> compressed WAL shouldn't be much even if you use gzip. It seems your
9.5 pg_xlog, low activity test cluster (segment switches forced
only by checkpoint timeouts), compressed with g
Artur Zakirov writes:
> On 25.07.2016 19:53, Peter Eisentraut wrote:
>> But I found that this actually talks about Hunspell format dictionaries.
>> (So the man page is hunspell(5) as opposed to ispell(5).) While as far
>> as the tsearch interfaces are concerned, those two are lumped together,
>>
Peter Eisentraut writes:
> On 7/22/16 7:01 PM, Andrew Gierth wrote:
>> In light of the fact that it is an endless cause of bugs both in pg and
>> potentially to applications, I propose that we cease attempting to
>> conform to the spec's definition of IS NULL in favour of the following
>> rules:
Michael Paquier writes:
> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood wrote:
>> Robbie Harwood writes:
>
> Sorry for my late reply.
Thanks for the feedback!
>>> If I were to continue as I have been - using the plaintext connection
>>> and auth negotiation path - then at the time of startu
Robbie Harwood writes:
> So there's a connection setting `sslmode` that we'll want something
> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
> think we only need three for GSSAPI: "disable", "allow", and "prefer"
> (which presumably would be the default).
Apologies, th
Robbie Harwood writes:
> So there's a connection setting `sslmode` that we'll want something
> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
> think we only need three for GSSAPI: "disable", "allow", and "prefer"
> (which presumably would be the default).
FWIW, there is
Hello folks,
I've got a small patch I'd like to submit for consideration.
The scenario involves MSVC builds, where a user can do the following:
1) Install ActivePerl's latest (5.22 or 5.24).
2) Add this line to their config.pl file (in src/tools/msvc):
$config->{perl} = "C:\\Perl64";
This will en
On Tue, Jul 26, 2016 at 11:10 AM, Tom Lane wrote:
>
> 3. Andrew also revived the bug #7808 thread in which it was complained
> that ExecMakeTableFunctionResult should not fail on null results from
> functions returning SETOF composite. That's related only in that the
> proposed fix is to transla
Tom Lane writes:
> Robbie Harwood writes:
>> So there's a connection setting `sslmode` that we'll want something
>> similar to here (`gssapimode` or so). `sslmode` has six settings, but I
>> think we only need three for GSSAPI: "disable", "allow", and "prefer"
>> (which presumably would be the
Hello,
The following article is a very good look at some of our limitations and
highlights some of the pains many of us have been working "around" since
we started using the software.
https://eng.uber.com/mysql-migration/
Specifically:
* Inefficient architecture for writes
* Inefficient dat
On Thu, Jul 21, 2016 at 12:06 PM, Robert Haas wrote:
> On Wed, Jul 20, 2016 at 9:15 PM, Noah Misch wrote:
>> This PostgreSQL 9.6 open item now needs a permanent owner. Would any other
>> committer like to take ownership? If this role interests you, please read
>> this thread and the policy link
"David G. Johnston" writes:
> The concept embodied by "NULL" in the operator "IS [NOT] NULL" is distinct
> from the concept embodied by "NULL" in the operator "IS [NOT] DISTINCT
> FROM".
> In short, the former smooths out the differences between composite and
> non-composite types while the later
On Tue, Jul 26, 2016 at 3:48 AM, Noah Misch wrote:
> On Thu, Jul 14, 2016 at 02:00:59AM +0200, Andreas Karlsson wrote:
>> On 07/09/2016 05:42 AM, David Rowley wrote:
>> >On 30 June 2016 at 03:49, Robert Haas wrote:
>> >>On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson
>> >>wrote:
>> >>>On 06/2
On Mon, Jun 6, 2016 at 3:30 AM, Michael Paquier
wrote:
> On Sun, Jun 5, 2016 at 11:16 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> Still, on back branches I think that it would be a good idea to have a
>>> better error message for the ones that already throw an error, like
>>> "trigger wit
On Fri, Jul 22, 2016 at 6:02 PM, Chapman Flack wrote:
> At $work, we have a usually-low-activity PG database, so that almost
> always the used fraction of each 16 MB WAL segment is far smaller
> than 16 MB, and so it's a big win for archived-WAL storage space
> if an archive-command can be written
On Fri, Jul 8, 2016 at 2:28 AM, Amit Kapila wrote:
> On Tue, May 31, 2016 at 10:10 PM, Robert Haas wrote:
>> On Fri, May 27, 2016 at 6:07 PM, Andrew Gierth
>> wrote:
>>> copyParamList does not respect from->paramMask, in what looks to me like
>>> an obvious oversight:
>>>
>>> retval->paramMa
On Mon, Jul 25, 2016 at 11:38 PM, David Fetter wrote:
> On Mon, Jul 25, 2016 at 11:12:24PM -0400, Robert Haas wrote:
>> On Fri, Jul 22, 2016 at 2:38 AM, David Fetter wrote:
>> > I've renamed it to require_where and contrib-ified.
>>
>> I'm not sure that the Authors section is entirely complete.
>
On 07/26/2016 09:54 AM, Joshua D. Drake wrote:
> Hello,
>
> The following article is a very good look at some of our limitations and
> highlights some of the pains many of us have been working "around" since
> we started using the software.
They also had other reasons to switch to MySQL, particul
On 07/26/2016 01:53 PM, Josh Berkus wrote:
> The write amplification issue, and its correllary in VACUUM, certainly
> continues to plague some users, and doesn't have any easy solutions.
To explain this in concrete terms, which the blog post does not:
1. Create a small table, but one with enough
On 07/26/2016 04:21 PM, Robert Haas wrote:
> I'm kind of curious WHY you are using archiving and forcing regular
> segment switches rather than just using streaming replication.
> ... AFAIK, streaming replication
> essentially obsoleted that use case. You can just dribble the
> individual bytes o
On Sat, Jul 23, 2016 at 3:55 AM, Amit Kapila wrote:
> Attached patch fixes the problem for me. Note, I have not tried to
> reproduce the problem for heap_lock_updated_tuple_rec(), but I think
> if you are convinced with above cases, then we should have a similar
> check in it as well.
I don't th
On Tue, Jul 26, 2016 at 02:26:57PM -0700, Josh Berkus wrote:
> On 07/26/2016 01:53 PM, Josh Berkus wrote:
> > The write amplification issue, and its correllary in VACUUM, certainly
> > continues to plague some users, and doesn't have any easy solutions.
>
> To explain this in concrete terms, which
On Tue, Jul 26, 2016 at 5:26 PM, Josh Berkus wrote:
> On 07/26/2016 01:53 PM, Josh Berkus wrote:
>> The write amplification issue, and its correllary in VACUUM, certainly
>> continues to plague some users, and doesn't have any easy solutions.
>
> To explain this in concrete terms, which the blog p
Josh Berkus writes:
> To explain this in concrete terms, which the blog post does not:
> 1. Create a small table, but one with enough rows that indexes make
> sense (say 50,000 rows).
> 2. Make this table used in JOINs all over your database.
> 3. To support these JOINs, index most of the colum
On 21/07/16 06:57, David Fetter wrote:
> Folks,
>
> 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?
I say I don't like this at all.
As mentioned e
On 07/26/2016 03:07 PM, Tom Lane wrote:
> Josh Berkus writes:
>> 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 minutes here), and
>> because of a
On Tue, Jul 26, 2016 at 6:07 PM, Tom Lane wrote:
> Josh Berkus writes:
>> To explain this in concrete terms, which the blog post does not:
>
>> 1. Create a small table, but one with enough rows that indexes make
>> sense (say 50,000 rows).
>
>> 2. Make this table used in JOINs all over your datab
On Wed, Jul 27, 2016 at 7:19 AM, Robert Haas wrote:
> I've seen multiple cases where this kind of thing causes a
> sufficiently large performance regression that the system just can't
> keep up. Things are OK when the table is freshly-loaded, but as soon
> as somebody runs a query on any table in
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Tue, Jul 26, 2016 at 4:50 PM, Noah Misch wrote:
> > [Action required within 72 hours. This is a generic notification.]
> >
> > The above-described topic is currently a PostgreSQL 9.6 open item. Stephen,
> > since you committed t
On Tue, Jul 5, 2016 at 07:41:15AM -0400, David G. Johnston wrote:
> Surely these beta testers would test against the RC before putting it into
> production so I don't see an issue. I tend to agree generally but the point
> of
> beta is to find bugs and solicit suggestions for improvement to fea
On Wed, Jul 27, 2016 at 7:35 AM, Tom Lane wrote:
> "David G. Johnston" writes:
>> The concept embodied by "NULL" in the operator "IS [NOT] NULL" is distinct
>> from the concept embodied by "NULL" in the operator "IS [NOT] DISTINCT
>> FROM".
>
>> In short, the former smooths out the differences be
On Tue, Jul 26, 2016 at 9:48 PM, Amit Kapila wrote:
> Does any body else see the use case
> reported by Chapman important enough that we try to have some solution
> for it in-core?
The lack of updates in the pg_lesslog project is a sign that it is not
that much used. I does not seem a good idea t
On 07/26/16 20:01, Michael Paquier wrote:
> On Tue, Jul 26, 2016 at 9:48 PM, Amit Kapila wrote:
>> Does any body else see the use case
>> reported by Chapman important enough that we try to have some solution
>> for it in-core?
>
> The lack of updates in the pg_lesslog project is a sign that it i
On Tue, Jul 26, 2016 at 04:39:14PM -0400, Robert Haas wrote:
> On Mon, Jul 25, 2016 at 11:38 PM, David Fetter wrote:
> > On Mon, Jul 25, 2016 at 11:12:24PM -0400, Robert Haas wrote:
> >> On Fri, Jul 22, 2016 at 2:38 AM, David Fetter wrote:
> >> > I've renamed it to require_where and contrib-ified
* Joshua D. Drake (j...@commandprompt.com) wrote:
> Hello,
>
> The following article is a very good look at some of our limitations
> and highlights some of the pains many of us have been working
> "around" since we started using the software.
>
> https://eng.uber.com/mysql-migration/
>
> Specif
Hi,
As previously mentioned, dynahash isn't particularly fast. In many cases
that doesn't particularly matter. But e.g. hash aggregation and bitmap
index scans are quite sensitive to hash performance.
The biggest problems with dynahash (also discussed at [1]) are
a) two level structure doubling
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 a risk that
>> records have not been replayed yet even if they hav
On 7/26/16 7:46 PM, Thomas Munro wrote:
> By the way, our documentation says that NOT NULL constraints are
> equivalent to CHECK (column_name IS NOT NULL). That is what the SQL
> standard says, but in fact our NOT NULL constraints are equivalent to
> CHECK (column_name IS DISTINCT FROM NULL). Sho
On 7/26/16 6:14 PM, Vik Fearing wrote:
> As mentioned elsewhere in the thread, you can just do WHERE true to get
> around it, so why on Earth have it PGC_SUSET?
I'm not sure whether it's supposed to guard against typos and possibly
buggy SQL string concatenation in application code. So it would h
On 27/07/16 03:15, Peter Eisentraut wrote:
> On 7/26/16 6:14 PM, Vik Fearing wrote:
>> As mentioned elsewhere in the thread, you can just do WHERE true to get
>> around it, so why on Earth have it PGC_SUSET?
>
> I'm not sure whether it's supposed to guard against typos and possibly
> buggy SQL str
On 7/5/16 4:24 AM, Albe Laurenz wrote:
> But notwithstanding your feeling that you would like your application
> to break if it makes use of this behaviour, it is a change that might
> make some people pretty unhappy - nobody can tell how many.
What is the use of the existing behavior? You get ba
On Wed, Jul 27, 2016 at 5:11 AM, Robert Haas wrote:
> Committed with minor kibitizing: you don't need an "else" after a
> statement that transfers control out of the function.
Thanks. Right, I forgot that.
> Shouldn't
> pg_get_function_arguments, pg_get_function_identity_arguments,
> pg_get_func
Peter Eisentraut writes:
> On 7/26/16 7:46 PM, Thomas Munro wrote:
>> By the way, our documentation says that NOT NULL constraints are
>> equivalent to CHECK (column_name IS NOT NULL). That is what the SQL
>> standard says, but in fact our NOT NULL constraints are equivalent to
>> CHECK (column_n
On 7/25/16 3:26 PM, Andrew Gierth wrote:
> The issue I ran into was the exact same one as in the JDBC thread I
> linked to earlier: correctly interpreting pg_index.indoption (to get the
> ASC / DESC and NULLS FIRST/LAST settings), which requires knowing
> whether amcanorder is true to determine whe
Peter Eisentraut writes:
> On 7/26/16 6:14 PM, Vik Fearing wrote:
>> As mentioned elsewhere in the thread, you can just do WHERE true to get
>> around it, so why on Earth have it PGC_SUSET?
> I'm not sure whether it's supposed to guard against typos and possibly
> buggy SQL string concatenation i
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 the community, and it would be nice if it was
> back-patched.
Peter Eisentraut writes:
> On 7/25/16 3:26 PM, Andrew Gierth wrote:
>> The issue I ran into was the exact same one as in the JDBC thread I
>> linked to earlier: correctly interpreting pg_index.indoption (to get the
>> ASC / DESC and NULLS FIRST/LAST settings), which requires knowing
>> whether amc
On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood wrote:
> Michael Paquier writes:
>
>> On Tue, Jul 26, 2016 at 5:58 AM, Robbie Harwood wrote:
>>> Robbie Harwood writes:
>>
>> Sorry for my late reply.
>
> Thanks for the feedback!
>
If I were to continue as I have been - using the plaintext
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Peter Eisentraut writes:
> > On 7/25/16 3:26 PM, Andrew Gierth wrote:
> >> The issue I ran into was the exact same one as in the JDBC thread I
> >> linked to earlier: correctly interpreting pg_index.indoption (to get the
> >> ASC / DESC and NULLS FIRST/LAST
At Tue, 26 Jul 2016 13:51:53 +0900, Amit Langote
wrote in
> > So, how about splitting the original equalTupleDescs into
> > equalTupleDescs and equalTupleConstraints ?
>
> Actually TupleConstr is *part* of the TupleDesc struct, which the
> relcache.c tries to preserve in *whole* across a relca
On 07/26/2016 06:25 PM, Peter Eisentraut wrote:
On 7/5/16 4:24 AM, Albe Laurenz wrote:
But notwithstanding your feeling that you would like your application
to break if it makes use of this behaviour, it is a change that might
make some people pretty unhappy - nobody can tell how many.
What is
Hi,
I noticed that currently the core doesn't show any information on the
target relations involved in a foreign/custom join in EXPLAIN, by
itself. Here is an example:
-- join two tables
EXPLAIN (COSTS false, VERBOSE)
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY
On Tue, Jul 26, 2016 at 8:27 PM, Stephen Frost wrote:
> * Joshua D. Drake (j...@commandprompt.com) wrote:
>> Hello,
>>
>> The following article is a very good look at some of our limitations
>> and highlights some of the pains many of us have been working
>> "around" since we started using the sof
On Wed, Jul 27, 2016 at 8:50 AM, Etsuro Fujita
wrote:
> Hi,
>
> I noticed that currently the core doesn't show any information on the
> target relations involved in a foreign/custom join in EXPLAIN, by itself.
> Here is an example:
>
> -- join two tables
> EXPLAIN (COSTS false, VERBOSE)
> SELECT
On Wed, Jul 27, 2016 at 03:24:28AM +0200, Vik Fearing wrote:
> On 27/07/16 03:15, Peter Eisentraut wrote:
> > On 7/26/16 6:14 PM, Vik Fearing wrote:
> >> As mentioned elsewhere in the thread, you can just do WHERE true
> >> to get around it, so why on Earth have it PGC_SUSET?
> >
> > I'm not sure
> "Robert" == Robert Haas writes:
Robert> So I think we instead ought to fix it as in the attached.
Robert>if (retval->paramMask != NULL &&
Robert> - !bms_is_member(i, retval->paramMask))
Robert> + !bms_is_member(i, from->paramMas
> I noticed that currently the core doesn't show any information on the
> target relations involved in a foreign/custom join in EXPLAIN, by
> itself. Here is an example:
>
> -- join two tables
> EXPLAIN (COSTS false, VERBOSE)
> SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER
On Wed, Jul 27, 2016 at 3:24 AM, Robert Haas wrote:
> On Sat, Jul 23, 2016 at 3:55 AM, Amit Kapila wrote:
>> Attached patch fixes the problem for me. Note, I have not tried to
>> reproduce the problem for heap_lock_updated_tuple_rec(), but I think
>> if you are convinced with above cases, then w
On Wed, Jul 27, 2016 at 2:03 AM, Robert Haas wrote:
> On Fri, Jul 8, 2016 at 2:28 AM, Amit Kapila wrote:
>> On Tue, May 31, 2016 at 10:10 PM, Robert Haas wrote:
>>> On Fri, May 27, 2016 at 6:07 PM, Andrew Gierth
>>> wrote:
copyParamList does not respect from->paramMask, in what looks to me
On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost wrote:
> That'd be great. It's definitely on my list of things to look into, but
> I'm extremely busy this week. I hope to look into it on Friday, would
> be great to see what you find.
Sequences that are directly defined in extensions do not get d
>I think we could do carry every 0x7FF / 1 accumulation, couldn't we?
I feel that I have to elaborate a bit. Probably my calculations are wrong.
Lets assume we already have accumulated INT_MAX of digits in
previous-place accumulator. That's almost overflow, but that's not
overflow. C
73 matches
Mail list logo
