On 02/05/2014 06:48 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 02/05/2014 11:40 AM, Tom Lane wrote:
>>> switching to "binary is the same as text" may well be the most prudent
>>> path here.
>> If we do that we're going to have to live with that forever, aren't we?
> Yeah, but the other si
Hi,
On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
> * switching to using text representation in jsonb send/recv
> +/*
> + * jsonb type recv function
> + *
> + * the type is sent as text in binary mode, so this is almost the same
> + * as the input function.
> + */
> +Datum
> +jsonb_recv(PG
On 02/10/2014 11:05 AM, Andres Freund wrote:
> Hi,
>
> On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
>> * switching to using text representation in jsonb send/recv
>> +/*
>> + * jsonb type recv function
>> + *
>> + * the type is sent as text in binary mode, so this is almost the same
>> + *
On Sun, Feb 9, 2014 at 7:37 PM, Alexander Korotkov wrote:
> This is not only place that worry me about planning overhead. See
> get_cheapest_fractional_path_for_pathkeys. I had to estimate number of
> groups for each sorting column in order to get right fractional path.
AFAICT this only happens o
On Sun, Feb 9, 2014 at 8:06 PM, Robert Haas wrote:
> On Fri, Feb 7, 2014 at 7:39 AM, Christian Convey
> wrote:
> > This question is mostly just curiosity...
>
> As someone very new to this code base, I think these cycles make it a
> little
> > harder to figure out the runtime and compile-time de
On 02/07/2014 01:27 PM, Peter Geoghegan wrote:
On Thu, Jan 16, 2014 at 12:35 AM, Heikki Linnakangas
wrote:
I think you should consider breaking off the relcache parts of my
patch and committing them, because they're independently useful.
Makes sense. Can you extract that into a separate patch
(2014/02/07 21:31), Etsuro Fujita wrote:
> So, I've modified the patch so
> that we continue to disallow SET STORAGE on a foreign table *in the same
> manner as before*, but, as your patch does, allow it on an inheritance
> hierarchy that contains foreign tables, with the semantics that we
> qu
On 02/10/2014 05:05 AM, Andres Freund wrote:
Hi,
On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
* switching to using text representation in jsonb send/recv
+/*
+ * jsonb type recv function
+ *
+ * the type is sent as text in binary mode, so this is almost the same
+ * as the input funct
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
> On 02/10/2014 05:05 AM, Andres Freund wrote:
> >I'd suggest making the format discernible from possible different future
> >formats, to allow introducing a proper binary at some later time. Maybe
> >just send a int8 first, containing the format.
On 02/10/2014 07:39 AM, Andres Freund wrote:
On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
On 02/10/2014 05:05 AM, Andres Freund wrote:
I'd suggest making the format discernible from possible different future
formats, to allow introducing a proper binary at some later time. Maybe
just se
On 01/31/2014 11:54 AM, Andres Freund wrote:
Hi,
On 2014-01-28 21:27:29 -0800, Peter Geoghegan wrote:
On Fri, Nov 15, 2013 at 11:47 AM, Andres Freund wrote:
1) I've added an abstracted atomic ops implementation. Needs a fair
amount of work, also submitted as a separate CF entry. (Patch 1
(2014/02/09 8:06), Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use of dllwrap and dlltool now. Isn't it better
Hi,
During the lwlock scalability work I noticed a longstanding issue with
the lwlock code. LWLockRelease() and the other mentioned locations do
the following to wake up any waiters, without holding the lock's
spinlock:
/*
* Awaken any waiters I removed from the queue.
*/
while (
Hello,
What I would like to do is to get the record in the table that a leaf GISTENTRY
points to, if that is possible.
I notice that GISTENTRY contains these members: Relation rel, Page page, and
OffsetNumber offset, but are these referring to the table or the index?
Thank you,
Marios Vodas
On Thu, Feb 6, 2014 at 5:57 PM, Amit Kapila wrote:
> On Thu, Feb 6, 2014 at 9:13 AM, Amit Kapila wrote:
> Considering above change as correct, I have tried to see the worst
> case overhead for this patch by having new tuple such that after
> 25% or so of suffix/prefix match, there is a small chan
Craig Ringer writes:
> On 02/06/2014 01:48 AM, Tom Lane wrote:
>>> switching to "binary is the same as text" may well be the most prudent
>>> path here.
> Can't we just reject attempts to transfer these via binary copy,
> allowing only a text format? So rather than sending text when the binary
>
Robert Haas writes:
> On Fri, Feb 7, 2014 at 7:39 AM, Christian Convey
> wrote:
>> As someone very new to this code base, I think these cycles make it a little
>> harder to figure out the runtime and compile-time dependencies between the
>> subsystems these directories seem to represent. I wonde
On Mon, Feb 10, 2014 at 10:28 AM, Tom Lane wrote:
> I think if it had been a clear, enforced goal all along, it might've been
> possible to build the system with such a restriction (for the most part at
> least). At this point though, the amount of work and code churn involved
> seems like it'd
Andres Freund writes:
> So what we need to do is to acquire a write barrier between the
> assignments to lwWaitLink and lwWaiting, i.e.
> proc->lwWaitLink = NULL;
> pg_write_barrier();
> proc->lwWaiting = false;
You didn't really explain why you think that ordering is nece
On 2014-02-10 11:11:28 -0500, Tom Lane wrote:
> Andres Freund writes:
> > So what we need to do is to acquire a write barrier between the
> > assignments to lwWaitLink and lwWaiting, i.e.
> > proc->lwWaitLink = NULL;
> > pg_write_barrier();
> > proc->lwWaiting = false;
>
>
On 2014-02-10 11:20:30 -0500, Tom Lane wrote:
> I wrote:
> > You didn't really explain why you think that ordering is necessary?
>
> Actually, after grepping to check my memory of what those fields are
> being used for, I have a bigger question: WTF is xlog.c doing being
> so friendly with the inn
Hello Marko
2014-01-16 23:54 GMT+01:00 Marko Tiikkaja :
> Hi Pavel,
>
> First of all, thanks for working on this!
>
>
> On 1/12/14, 8:58 PM, Pavel Stehule wrote:
>
>> I still not happy with plugin_info - it is only per plugin now and should
>> be per plugin and per function.
>>
>
> I'm not sure
I wrote:
> You didn't really explain why you think that ordering is necessary?
Actually, after grepping to check my memory of what those fields are
being used for, I have a bigger question: WTF is xlog.c doing being
so friendly with the innards of LWLocks? Surely this needs to get
refactored so t
On Sun, Feb 9, 2014 at 4:56 PM, Robert Haas wrote:
> On Sun, Feb 9, 2014 at 6:33 PM, Jeff Janes wrote:
> >
> > Since this commit (17676c785a95b2598c573), pgbench no longer uses
> .pgpass to
> > obtain passwords, but instead prompts for a password
> >
> > This problem is in 9.3 and 9.4dev
> >
> >
On 02/10/2014 06:41 PM, Andres Freund wrote:
On 2014-02-10 11:20:30 -0500, Tom Lane wrote:
I wrote:
You didn't really explain why you think that ordering is necessary?
Actually, after grepping to check my memory of what those fields are
being used for, I have a bigger question: WTF is xlog.c
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund wrote:
> On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
>> On 02/10/2014 05:05 AM, Andres Freund wrote:
>> >I'd suggest making the format discernible from possible different future
>> >formats, to allow introducing a proper binary at some later t
Heikki Linnakangas writes:
> On 02/10/2014 06:41 PM, Andres Freund wrote:
>> Well, it's not actually using any lwlock.c code, it's a special case
>> locking logic, just reusing the datastructures. That said, I am not
>> particularly happy about the amount of code it's duplicating from
>> lwlock.c.
On Mon, Feb 10, 2014 at 11:57 AM, Heikki Linnakangas
wrote:
> The relcache parts? I don't think a separate patch ever appeared that could
> be reviewed.
I posted the patch on January 18th:
http://www.postgresql.org/message-id/cam3swzth4vkesot7dcrwbprn7zzhnz-wa6zmvo1ff7gbnoj...@mail.gmail.com
I
On 02/10/2014 03:46 PM, Andres Freund wrote:
Hi,
During the lwlock scalability work I noticed a longstanding issue with
the lwlock code. LWLockRelease() and the other mentioned locations do
the following to wake up any waiters, without holding the lock's
spinlock:
/*
* Awaken any wait
Merlin Moncure writes:
> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund wrote:
>> On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
>>> Teodor privately suggested something similar. I was thinking of just
>>> sending a version byte, which for now would be '\x01'. An int8 seems like
>>> more fu
On 02/09/2014 02:17 PM, Magnus Hagander wrote:
If an error occurs in the foreground (backup) process of pg_basebackup, and
we exit in a controlled way, the background process (streaming xlog
process) would stay around and keep streaming.
This can happen for example if disk space runs out and the
On 02/10/2014 08:03 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 02/10/2014 06:41 PM, Andres Freund wrote:
Well, it's not actually using any lwlock.c code, it's a special case
locking logic, just reusing the datastructures. That said, I am not
particularly happy about the amount of code i
On Sun, Jan 19, 2014 at 2:17 AM, Peter Geoghegan wrote:
> I'm just throwing an error when locking the tuple returns
> HeapTupleInvisible, and the xmin of the tuple is our xid.
I would like some feedback on this point. We need to consider how
exactly to avoid updating the same tuple inserted by ou
On Mon, Feb 10, 2014 at 7:29 PM, Heikki Linnakangas wrote:
> On 02/09/2014 02:17 PM, Magnus Hagander wrote:
>
>> If an error occurs in the foreground (backup) process of pg_basebackup,
>> and
>> we exit in a controlled way, the background process (streaming xlog
>> process) would stay around and
On Mon, Feb 10, 2014 at 2:33 PM, Marti Raudsepp wrote:
> On Sun, Feb 9, 2014 at 7:37 PM, Alexander Korotkov
> wrote:
> > This is not only place that worry me about planning overhead. See
> > get_cheapest_fractional_path_for_pathkeys. I had to estimate number of
> > groups for each sorting column
On Mon, Feb 10, 2014 at 12:15 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund
>> wrote:
>>> On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
Teodor privately suggested something similar. I was thinking of just
sending a version byte,
Hi!
On Tue, Jan 28, 2014 at 9:34 PM, Thom Brown wrote:
> And I'd be fine with being admin again this year, unless there's
> anyone else who would like to take up the mantle?
>
Thanks for your work. I would like to see you as admin this year again.
Who would be up for mentoring this year? And
On 2014-02-10 19:48:47 +0200, Heikki Linnakangas wrote:
> On 02/10/2014 06:41 PM, Andres Freund wrote:
> >On 2014-02-10 11:20:30 -0500, Tom Lane wrote:
> >>I wrote:
> >>>You didn't really explain why you think that ordering is necessary?
> >>
> >>Actually, after grepping to check my memory of what
On 2014-02-10 11:59:53 -0600, Merlin Moncure wrote:
> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund wrote:
> > On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
> >> On 02/10/2014 05:05 AM, Andres Freund wrote:
> >> >I'd suggest making the format discernible from possible different future
> >>
On Mon, Feb 10, 2014 at 5:02 PM, Andres Freund wrote:
> On 2014-02-10 11:59:53 -0600, Merlin Moncure wrote:
>> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund
>> wrote:
>> > On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
>> >> On 02/10/2014 05:05 AM, Andres Freund wrote:
>> >> >I'd suggest m
On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
> Wrong. You still need to have code that checks the server version and
> see if it's supported (particularly for sending) and as there is *no
> protocol negotiation of the formats at present it's all going to boil
> down to if version = X do Y*.
On Mon, Feb 10, 2014 at 5:38 PM, Andres Freund wrote:
> On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
>> Wrong. You still need to have code that checks the server version and
>> see if it's supported (particularly for sending) and as there is *no
>> protocol negotiation of the formats at pr
On 2014-02-10 17:48:32 -0600, Merlin Moncure wrote:
> On Mon, Feb 10, 2014 at 5:38 PM, Andres Freund wrote:
> > On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
> >> Wrong. You still need to have code that checks the server version and
> >> see if it's supported (particularly for sending) and
On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund wrote:
> It works in enough cases atm that it's worthwile trying to keep it
> working. Sure, it could be better, but it's what we have right now. Atm
> it's e.g. the only realistic way to copy larger amounts of bytea between
> servers without copying
2014-02-08 4:52 GMT+09:00 Robert Haas :
> On Tue, Jan 21, 2014 at 11:37 AM, Robert Haas wrote:
>> One idea I just had is to improve the dsm_toc module so that it can
>> optionally set up a tranche of lwlocks for you, and provide some
>> analogues of RequestAddinLWLocks and LWLockAssign for that ca
On 2014-02-10 18:16:15 -0600, Merlin Moncure wrote:
> On Mon, Feb 10, 2014 at 5:52 PM, Andres Freund wrote:
> > It works in enough cases atm that it's worthwile trying to keep it
> > working. Sure, it could be better, but it's what we have right now. Atm
> > it's e.g. the only realistic way to cop
Merlin Moncure writes:
> right, json could be made work, but any other format change introduced
> to any other already existing type will break. That's not a real
> solution unless we decree henceforth that no formats will change from
> here on in, in which case I withdraw my objection.
Well, I
On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund wrote:
> And if we add a new format version in 9.5 we need to make it discernible
> from the 9.4 format. Without space for a format indicator we'd have to
> resort to ugly tricks like defining the high bit in the first byte set
> indicates the new ver
Merlin Moncure writes:
> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund wrote:
>> And if we add a new format version in 9.5 we need to make it discernible
>> from the 9.4 format. Without space for a format indicator we'd have to
>> resort to ugly tricks like defining the high bit in the first byt
On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund
>> wrote:
>>> And if we add a new format version in 9.5 we need to make it discernible
>>> from the 9.4 format. Without space for a format indicator we'd have to
>>> resor
On 2014-02-10 19:01:48 -0600, Merlin Moncure wrote:
> On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane wrote:
> > Merlin Moncure writes:
> >> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund
> >> wrote:
> >>> And if we add a new format version in 9.5 we need to make it discernible
> >>> from the 9.4 for
On 10 February 2014 20:11, Hannu Krosing wrote:
> The fastest and lowest parsing cost format for "JSON" is tnetstrings
> http://tnetstrings.org/ why not use it as the binary wire format ?
>
> It would be as binary as it gets and still be generally parse-able by
> lots of different platforms, at le
On Monday, February 10, 2014, Andres Freund wrote:
> On 2014-02-10 19:01:48 -0600, Merlin Moncure wrote:
> > On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane >
> wrote:
> > > Merlin Moncure > writes:
> > >> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund <
> and...@2ndquadrant.com > wrote:
> > >>> And if
Hi,
Is it just me or is jsonapi.h not very well documented?
On 2014-02-06 18:47:31 -0500, Andrew Dunstan wrote:
> +/*
> + * for jsonb we always want the de-escaped value - that's what's in token
> + */
> +static void
> +jsonb_in_scalar(void *state, char *token, JsonTokenType tokentype)
> +{
> +
committed
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/10/2014 08:50 PM, Tom Dunstan wrote:
On 10 February 2014 20:11, Hannu Krosing wrote:
The fastest and lowest parsing cost format for "JSON" is tnetstrings
http://tnetstrings.org/ why not use it as the binary wire format ?
It would be as binary as it gets and still be generally parse-able
On 02/10/2014 09:11 PM, Andres Freund wrote:
diff --git a/src/backend/utils/adt/jsonfuncs.c
b/src/backend/utils/adt/jsonfuncs.c
index e1d8aae..50ddf50 100644
--- a/src/backend/utils/adt/jsonfuncs.c
+++ b/src/backend/utils/adt/jsonfuncs.c
there's lots of whitespace/tab damage in this file. Chec
On 2014-02-10 22:15:21 -0500, Andrew Dunstan wrote:
>
> On 02/10/2014 09:11 PM, Andres Freund wrote:
> >>diff --git a/src/backend/utils/adt/jsonfuncs.c
> >>b/src/backend/utils/adt/jsonfuncs.c
> >>index e1d8aae..50ddf50 100644
> >>--- a/src/backend/utils/adt/jsonfuncs.c
> >>+++ b/src/backend/utils
(2014/02/10 22:42), Hiroshi Inoue wrote:
(2014/02/09 8:06), Andrew Dunstan wrote:
On 02/08/2014 05:34 PM, Tom Lane wrote:
Hiroshi Inoue writes:
Though I'm not a MINGW expert at all, I know dllwrap is a deprecated
tool and dlltool is almost a deprecated tool. Cygwin port is removing
the use o
"Inoue, Hiroshi" writes:
> (2014/02/10 22:42), Hiroshi Inoue wrote:
>> I tried MINGW port with the attached change and successfully built
>> src and contrib and all pararell regression tests were OK.
> I forgot to mention the environment. I tried the change in 2 machines
> and both worked.
If th
On 02/11/2014 01:28 PM, Tom Lane wrote:
> If there are no objections, I'll push this patch into HEAD tomorrow,
> along with the upthread patches from Craig Ringer and Marco Atzeri.
> We might as well see if this stuff is going to work ...
I'd love to test my patch properly before pushing it, but m
61 matches
Mail list logo
