On 14/09/14 20:43, Mark Kirkwood wrote:
On 14/09/14 20:24, Atri Sharma wrote:
How do you plan to do all that VACUUM does for this table then?
It seems to me that you are saying to VACUUM that it need not be
concerned with table 'A' and you are assuming ownership of all the tasks
performed by
On 09/15/2014 07:51 AM, Noah Misch wrote:
libintl replaces setlocale(). Its setlocale(LC_x, ) uses OS-specific APIs
to determine the default locale when $LANG and similar environment variables
are empty, as they are during make check NO_LOCALE=1. On OS X, it calls[1]
CFLocaleCopyCurrent(),
On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. If that's what the browsers do, I think we should also err on the
side of caution here. Ignoring the CN is highly unlikely to cause anyone
a problem; a CA worth its salt should not issue a certificate with
On 09/13/2014 11:25 AM, Fabien COELHO wrote:
[about logging...]
Here is an attempt at updating the log features, including the aggregate
and sampling stuff, with skipped transactions under throttling.
I moved the logging stuff into a function which is called when a
transaction is skipped or
On Mon, Sep 15, 2014 at 10:23 AM, Alexey Klyukin al...@hintbits.com wrote:
On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Hmm. If that's what the browsers do, I think we should also err on the
side of caution here. Ignoring the CN is highly unlikely to
On 09/15/2014 02:42 AM, Arthur Silva wrote:
Em 14/09/2014 12:21, Andres Freund and...@2ndquadrant.com escreveu:
On 2014-09-13 20:27:51 -0500, k...@rice.edu wrote:
What we are looking for here is uniqueness thus better error
detection. Not
avalanche effect, nor cryptographically secure, nor
On 09/14/2014 11:34 PM, Peter Geoghegan wrote:
On Sun, Sep 14, 2014 at 7:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Both values vary in range 5.9 - 6.1 s, so it's fair to say that the useless
memcmp() is free with these parameters.
Is this the worst case scenario?
Other than
This patch has been sitting in the commitfest with no activity since
this email from July. What's the real status, who's got the ball on this
one? Please update the commitfest app accordingly. If nothing happens in
the next few days, I'll mark this as Returned with Feedback.
On 07/09/2014
On Sun, Sep 14, 2014 at 7:39 AM, Peter Geoghegan p...@heroku.com wrote:
On Fri, Sep 12, 2014 at 2:19 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
Actually, higher cardinality skip columns is better. Sorting of smaller
groups is faster than sorting larger groups of same size. Also,
On Sun, Sep 14, 2014 at 9:32 AM, Peter Geoghegan p...@heroku.com wrote:
I think we might be better off if a tuplesort function was called
shortly after tuplesort_begin_heap() is called. How top-n heap sorts
work is something that largely lives in tuplesort's head. Today, we
call
On Thu, Sep 11, 2014 at 8:40 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
On Thu, Sep 11, 2014 at 11:24 AM, Kouhei Kaigai
kai...@ak.jp.nec.com
wrote:
Don't the changes to src/backend/optimizer/plan/createplan.c
belong in patch #2?
The borderline between #1 and #2 is little bit
On 09/15/2014 01:44 PM, Alexey Klyukin wrote:
Committed, with that change, ie. the CN is not checked if SANs are present.
Actually, I disagree with the way the patch ignores the CN. Currently,
it skips the
CN unconditionally if the SubjectAltName section is present. But what
RFC 6125 says
is:
Hi!
9.4 GIN introduces new triconsistent method which can return one of three
values in spite of just consistent method. But in catalog declaration
triconsistent still returns bool type. It doesn't affect anything because
nobody calls triconsistent from SQL. But I think it would be correct to
On 09/15/2014 04:58 PM, Alexander Korotkov wrote:
Hi!
9.4 GIN introduces new triconsistent method which can return one of three
values in spite of just consistent method. But in catalog declaration
triconsistent still returns bool type. It doesn't affect anything because
nobody calls
On Mon, Sep 15, 2014 at 10:11:57AM +0300, Heikki Linnakangas wrote:
On 09/15/2014 07:51 AM, Noah Misch wrote:
libintl replaces setlocale(). Its setlocale(LC_x, ) uses OS-specific APIs
to determine the default locale when $LANG and similar environment variables
are empty, as they are during
Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 08/30/2014 12:15 AM, Kevin Grittner wrote:
If we were to go with the hooks as you propose, we would still need
to take the information from TriggerData and put it somewhere else
for the hook to
Hackers,
some GIN opclasses uses collation-aware comparisons while they don't need
to do especially collation-aware comparison. Examples are text[] and hstore
opclasses. Depending on collation this may make them a much slower.
See example.
# show lc_collate ;
lc_collate
─
Hi hackers,
An issue that seems related to this has been posted on pgsql-admin. See:
http://www.postgresql.org/message-id/caas3tylnxaydz0+zhxlpdvtovhqovr+jsphp30o8kvwqqs0...@mail.gmail.com
How can we help on this issue?
Cheers,
On Thu, 4 Sep 2014 17:50:36 +0200
Jehan-Guillaume de Rorthais
On Sun, Sep 14, 2014 at 4:37 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 12 September 2014 18:19, Simon Riggs si...@2ndquadrant.com wrote:
On 12 September 2014 15:30, Tom Lane t...@sss.pgh.pa.us wrote:
After a little bit I remembered there was already a function for this.
So specifically,
On Sun, Sep 14, 2014 at 5:18 AM, Rohit Goyal rhtgyl...@gmail.com wrote:
Thanks for reply. But, I think i confused you. I am talking about access
using indexes. So, I assume that B+ tree store key-value pair where rohit is
the key and all the versions are its value.
Another way to think is I
On Mon, Sep 15, 2014 at 6:34 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Please have a look. I have not looked at the docs changes yet.
One thing that needs some thinking and changing is the progress reporting.
It currently looks like this:
progress: 1.0 s, 4863.0 tps, lat 3.491 ms
On 09/12/2014 01:33 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
However, this better become a FAQ item, because it's not necessarily the
behavior that folks used to JSON but not Postgres will expect.
No, it's a bug, not a documentation deficiency.
Hmmm? Are you proposing that
On 09/12/2014 01:30 PM, Heikki Linnakangas wrote:
Performance was one argument for sure. It's not hard to come up with a
case where the all-lengths approach is much slower: take a huge array
with, say, million elements, and fetch the last element in a tight loop.
And do that in a PL/pgSQL
On Sun, Sep 14, 2014 at 10:37 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 09/13/2014 11:28 PM, Peter Geoghegan wrote:
Anyway, attached rough test program implements what you outline. This
is for 30,000 32 byte strings (where just the final two bytes differ).
On my laptop, output
On Mon, Sep 15, 2014 at 2:12 PM, Josh Berkus j...@agliodbs.com wrote:
If not, I think the corner case is so obscure as to be not worth
optimizing for. I can't imagine that more than a tiny minority of our
users are going to have thousands of keys per datum.
Worst case is linear cost scaling
On Mon, Sep 15, 2014 at 8:38 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The only reason why I put separate hooks here is, create_custom_scan()
needs to know exact size of the CustomScan node (including private
fields), however, it is helpful for extensions to kick its callback to
On Mon, Sep 15, 2014 at 10:17 AM, Robert Haas robertmh...@gmail.com wrote:
It strikes me that perhaps we should make this change (rearranging
things so that the memcmp tiebreak is run before strcoll) first,
before dealing with the rest of the abbreviated keys infrastructure.
It appears to be a
I'm not sure I like the idea of printing a percentage. It might be
unclear what the denominator was if somebody feels the urge to work
back to the actual number of skipped transactions. I mean, I guess
it's probably just the value you passed to -R, so maybe that's easy
enough, but then why
On Mon, Sep 15, 2014 at 1:34 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 10:17 AM, Robert Haas robertmh...@gmail.com wrote:
It strikes me that perhaps we should make this change (rearranging
things so that the memcmp tiebreak is run before strcoll) first,
before dealing
On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
That makes for a bit awkward input and output from psql, when the values
used are 0, 1, 2, rather than ascii characters. But that's OK, because as
you said these functions are not callable from psql anyway, as
On Mon, Sep 15, 2014 at 10:53 AM, Robert Haas robertmh...@gmail.com wrote:
I think there's probably more than that to work out, but in any case
there's no harm in getting a simple optimization done first before
moving on to a complicated one.
I guess we never talked about the abort logic in
Josh Berkus j...@agliodbs.com writes:
On 09/12/2014 01:33 PM, Tom Lane wrote:
No, it's a bug, not a documentation deficiency.
Hmmm? Are you proposing that we should change how ARRAY @ ARRAY works
for non-JSON data?
No.
Or are you proposing that JSONARRAY @ JSONARRAY should work
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
This requires a catalog change to fix. Are we still planning to do a
catversion bump for 9.4 because of the jsonb changes?
That was my understanding, although we seem
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I'd think that we should retain it for objects; Peter's
main argument against that was that the comment would be too complicated,
but that seems a bit silly from here.
I just don't see any point to it. My argument
On Mon, Sep 15, 2014 at 1:55 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 10:53 AM, Robert Haas robertmh...@gmail.com wrote:
I think there's probably more than that to work out, but in any case
there's no harm in getting a simple optimization done first before
moving on
On Mon, Sep 15, 2014 at 11:20 AM, Robert Haas robertmh...@gmail.com wrote:
...looks like about a 10-line patch. We have the data to show that
the loss is trivial even in the worst case, and we have or should be
able to get data showing that the best-case win is significant even
without the
On Mon, Sep 15, 2014 at 2:18 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I'd think that we should retain it for objects; Peter's
main argument against that was that the comment would be too complicated,
but that
Peter Geoghegan p...@heroku.com writes:
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I'd think that we should retain it for objects; Peter's
main argument against that was that the comment would be too complicated,
but that seems a bit silly from here.
I
On Mon, Sep 15, 2014 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It might be that the benefit is very close to nil; that would depend a lot
on workload, so it's hard to be sure. I'd say though that the cost is
also very close to nil, in the sense that we're considering two additional
On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
some GIN opclasses uses collation-aware comparisons while they don't need to
do especially collation-aware comparison. Examples are text[] and hstore
opclasses. Depending on collation this may make them a much
On Sat, Sep 13, 2014 at 3:56 AM, Robert Haas robertmh...@gmail.com wrote:
I think so. If we make it a function, then it's either the kind of
function that you access via pg_proc, or it's the kind that's written
in C and installed by storing a function pointer in a hook variable
from
On Mon, Sep 15, 2014 at 10:51 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
some GIN opclasses uses collation-aware comparisons while they don't
need to
do especially collation-aware comparison. Examples are
On 09/15/2014 10:23 AM, Claudio Freire wrote:
Now, large small keys could be 200 or 2000, or even 20k. I'd guess
several should be tested to find the shape of the curve.
Well, we know that it's not noticeable with 200, and that it is
noticeable with 100K. It's only worth testing further if we
On Mon, Sep 15, 2014 at 4:09 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/15/2014 10:23 AM, Claudio Freire wrote:
Now, large small keys could be 200 or 2000, or even 20k. I'd guess
several should be tested to find the shape of the curve.
Well, we know that it's not noticeable with 200, and
On 09/15/2014 12:15 PM, Claudio Freire wrote:
So while you're right that it's perhaps above what would be a common
use case, the range somewhere between 200 and 100K for the tipping
point seems overly imprecise to me.
Well, then, you know how to solve that.
--
Josh Berkus
PostgreSQL Experts
On Mon, Sep 15, 2014 at 4:17 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/15/2014 12:15 PM, Claudio Freire wrote:
So while you're right that it's perhaps above what would be a common
use case, the range somewhere between 200 and 100K for the tipping
point seems overly imprecise to me.
Peter Geoghegan p...@heroku.com writes:
On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
Rename such opclasses and make them not default.
Create new default opclasses with bitwise comparison functions.
Write recommendation to re-create indexes with default
On 09/15/2014 12:25 PM, Claudio Freire wrote:
On Mon, Sep 15, 2014 at 4:17 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/15/2014 12:15 PM, Claudio Freire wrote:
So while you're right that it's perhaps above what would be a common
use case, the range somewhere between 200 and 100K for the
On 15 September 2014 17:09, Robert Haas robertmh...@gmail.com wrote:
Do we really want to disable HOT for all catalog scans?
The intention of the patch is that catalog scans are treated
identically to non-catalog scans. The idea here is that HOT cleanup
only occurs on scans on target relations,
On Mon, Sep 15, 2014 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/15/2014 10:23 AM, Claudio Freire wrote:
Now, large small keys could be 200 or 2000, or even 20k. I'd guess
several should be tested to find the shape of the curve.
Well, we know that it's not noticeable with 200, and
On Mon, Sep 15, 2014 at 12:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No. And we don't know how to change the default opclass without
breaking things, either.
Is there a page on the Wiki along the lines of things that we would
like to change if ever there is a substantial change in on-disk
On 09/15/2014 02:16 PM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 3:09 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/15/2014 10:23 AM, Claudio Freire wrote:
Now, large small keys could be 200 or 2000, or even 20k. I'd guess
several should be tested to find the shape of the curve.
Well, we
On Fri, Sep 12, 2014 at 5:42 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 09/12/2014 11:38 AM, Heikki Linnakangas wrote:
Now that the logic is fixed, I hope we
won't get complaints that the indexes are bigger, if you fill a table by
appending to the end. I wonder if we should aim
On Mon, Sep 15, 2014 at 11:25 AM, Peter Geoghegan p...@heroku.com wrote:
OK, I'll draft a patch for that today, including similar alterations
to varstr_cmp() for the benefit of Windows and so on.
I attach a much simpler patch, that only adds an opportunistic
memcmp() == 0 before a possible
El 14/09/14 17:37, Simon Riggs escribió:
On 12 September 2014 18:19, Simon Riggs si...@2ndquadrant.com wrote:
On 12 September 2014 15:30, Tom Lane t...@sss.pgh.pa.us wrote:
After a little bit I remembered there was already a function for this.
So specifically, I'd suggest using
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, having the keys all at the same level *is* relevant for the
issue we're discussing. If those 270 keys are organized in a tree, it's
not the same as having them all on one level (and not as problematic).
I believe
On Mon, Sep 15, 2014 at 4:21 PM, Peter Geoghegan p...@heroku.com wrote:
I attach a much simpler patch, that only adds an opportunistic
memcmp() == 0 before a possible strcoll(). Both
bttextfastcmp_locale() and varstr_cmp() have the optimization added,
since there is no point in leaving anyone
I couldn't get my hands on the twitter data but I'm generating my own. The
json template is http://paste2.org/wJ1dfcjw and data was generated with
http://www.json-generator.com/. It has 35 top level keys, just in case
someone is wondering.
I generated 1 random objects and I'm inserting them
On 09/16/2014 07:44 AM, Peter Geoghegan wrote:
FWIW, I am slightly concerned about weighing use cases around very
large JSON documents too heavily. Having enormous jsonb documents just
isn't going to work out that well, but neither will equivalent designs
in popular document database systems
Heikki Linnakangas wrote:
Here we go. I've split this again into two patches. The first patch
is just refactoring the current code. It moves XLogInsert into a new
file, xloginsert.c, and the definition of XLogRecord to new
xlogrecord.h header file. As a result, there is a a lot of churn in
(2014/09/13 0:13), Tom Lane wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Tom Lane wrote:
I'm not sure offhand what the new plan tree ought to look like. We could
just generate a ForeignScan node, but that seems like rather a misnomer.
Is it worth inventing a new ForeignUpdate node
On Mon, Sep 15, 2014 at 7:03 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Heikki Linnakangas wrote:
Here we go. I've split this again into two patches. The first patch
is just refactoring the current code. It moves XLogInsert into a new
file, xloginsert.c, and the definition of
Jan Wieck wrote:
On 09/14/2014 02:25 PM, Pavel Stehule wrote:
a) Isn't possible handle a assertion exception anywhere .. it enforce
ROLLBACK in 100%
b) Assertions should be disabled globally .. I am not sure, it it is a
good idea, but I can understand so some tests based on queries to data
On Mon, Sep 15, 2014 at 8:00 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Alvaro got faster than me... I was just looking at the first patch and
+1 on those comments. It is worth noting that the first patch, as it
does only a large refactoring, does not impact performance or size of
64 matches
Mail list logo
