On 09/15/2014 08:56 PM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
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 fro
I'd like to propose support for IN and OUT parameters in 'DO' blocks.
Currently, anonymous code blocks (DO statements) can not receive or
return parameters.
I suggest:
1) Add a new clause to DO statement for specifying names, types,
directions and values of parameters:
DO [LANGUAGE ] [USING ()
On Mon, Sep 15, 2014 at 8:00 PM, Michael Paquier
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
> WAL records.
Some comme
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 querie
On Mon, Sep 15, 2014 at 7:03 PM, Alvaro Herrera
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 XLogRecord to new
>> xlog
(2014/09/13 0:13), Tom Lane wrote:
> Albe Laurenz 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 type? Or maybe
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
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 system
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 rep
On Mon, Sep 15, 2014 at 4:21 PM, Peter Geoghegan 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 out for t
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus 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 Robert meant th
El 14/09/14 17:37, Simon Riggs escribió:
> On 12 September 2014 18:19, Simon Riggs wrote:
>> On 12 September 2014 15:30, Tom Lane wrote:
>>> After a little bit I remembered there was already a function for this.
>>> So specifically, I'd suggest using ExecRelationIsTargetRelation()
>>> to decide
On Mon, Sep 15, 2014 at 11:25 AM, Peter Geoghegan 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 strcoll(). Both
On Fri, Sep 12, 2014 at 5:42 PM, Heikki Linnakangas
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 at an even more
On 09/15/2014 02:16 PM, Robert Haas wrote:
> On Mon, Sep 15, 2014 at 3:09 PM, Josh Berkus 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
On Mon, Sep 15, 2014 at 12:45 PM, Tom Lane 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 format
that will bre
On Mon, Sep 15, 2014 at 3:09 PM, Josh Berkus 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 that it is
On 15 September 2014 17:09, Robert Haas 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, so only INSERT, UPDA
On 09/15/2014 12:25 PM, Claudio Freire wrote:
> On Mon, Sep 15, 2014 at 4:17 PM, Josh Berkus 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
>>>
Peter Geoghegan writes:
> On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov
> 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 opclasses into
>> documentation.
On Mon, Sep 15, 2014 at 4:17 PM, Josh Berkus 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.
>
> Well, then,
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 Expe
On Mon, Sep 15, 2014 at 4:09 PM, Josh Berkus 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 that it is
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 10:51 PM, Peter Geoghegan wrote:
> On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov
> 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. D
On Sat, Sep 13, 2014 at 3:56 AM, Robert Haas 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 _PG_init(). The first appr
On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov
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 slower.
I'm glad that
On Mon, Sep 15, 2014 at 11:29 AM, Tom Lane 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
> compare-and-branch
Peter Geoghegan writes:
> On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane 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
On Mon, Sep 15, 2014 at 2:18 PM, Peter Geoghegan wrote:
> On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane 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.
>
On Mon, Sep 15, 2014 at 11:20 AM, Robert Haas 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 abbreviated key stuf
On Mon, Sep 15, 2014 at 1:55 PM, Peter Geoghegan wrote:
> On Mon, Sep 15, 2014 at 10:53 AM, Robert Haas 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 gue
Robert Haas writes:
> On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
> 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 to be proceeding at an
> inexplicably
On Mon, Sep 15, 2014 at 11:12 AM, Tom Lane 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 against the comp
Josh Berkus 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 differently
> from A
On Mon, Sep 15, 2014 at 10:53 AM, Robert Haas 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 all that much detail.
On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
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 they have
> "internal"
On Mon, Sep 15, 2014 at 1:34 PM, Peter Geoghegan wrote:
> On Mon, Sep 15, 2014 at 10:17 AM, Robert Haas 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 abbreviat
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 bot
On Mon, Sep 15, 2014 at 10:17 AM, Robert Haas 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 separate improvem
On Mon, Sep 15, 2014 at 8:38 AM, Kouhei Kaigai 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
>> > initialize the
On Mon, Sep 15, 2014 at 2:12 PM, Josh Berkus 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 vs number of key
On Sun, Sep 14, 2014 at 10:37 AM, Heikki Linnakangas
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 looks like this (e
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/pgSQ
On 09/12/2014 01:33 PM, Tom Lane wrote:
> Josh Berkus 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 we should
On Mon, Sep 15, 2014 at 6:34 AM, Heikki Linnakangas
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 stddev 2.487, lag
On Sun, Sep 14, 2014 at 5:18 AM, Rohit Goyal 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 have a secondary
On Sun, Sep 14, 2014 at 4:37 PM, Simon Riggs wrote:
> On 12 September 2014 18:19, Simon Riggs wrote:
>> On 12 September 2014 15:30, Tom Lane wrote:
>
>>> After a little bit I remembered there was already a function for this.
>>> So specifically, I'd suggest using ExecRelationIsTargetRelation()
>
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
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
─
ru_RU.UTF
Tom Lane wrote:
> Heikki Linnakangas 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 reference.
>
>> Sure.
>
> FWIW, I agre
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 d
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 triconsiste
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
decl
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:
> On Thu, Sep 11, 2014 at 8:40 PM, Kouhei Kaigai wrote:
> >> On Thu, Sep 11, 2014 at 11:24 AM, Kouhei Kaigai
> >>
> >> 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 bogus. So, I
On Sun, Sep 14, 2014 at 9:32 AM, Peter Geoghegan 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 tuplesort_set_bound() to
On Sun, Sep 14, 2014 at 7:39 AM, Peter Geoghegan wrote:
> On Fri, Sep 12, 2014 at 2:19 PM, Alexander Korotkov
> wrote:
> > Actually, higher cardinality skip columns is better. Sorting of smaller
> > groups is faster than sorting larger groups of same size. Also, with
> smaller
> > groups you ach
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 03:5
On 09/14/2014 11:34 PM, Peter Geoghegan wrote:
On Sun, Sep 14, 2014 at 7:37 AM, Heikki Linnakangas
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 pushing the differences mu
On 09/15/2014 02:42 AM, Arthur Silva wrote:
Em 14/09/2014 12:21, "Andres Freund" 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 bit distribution.
As
On Mon, Sep 15, 2014 at 10:23 AM, Alexey Klyukin wrote:
> On Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
> 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 wort
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 Fri, Sep 12, 2014 at 4:20 PM, Heikki Linnakangas
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 a CN
>> that's not
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(),
65 matches
Mail list logo
