2010/11/21 Robert Haas :
> On Sat, Nov 20, 2010 at 7:29 AM, Pavel Stehule
> wrote:
>> 2010/11/20 Robert Haas :
>>> On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule
>>> wrote:
I think so you are a correct. Who will a submit this final version? You or
me?
>>>
>>> I've got it.
>>>
>>
>> T
I've got a new stripped down version of the binary json plugin on github:
https://github.com/tlaurenzo/pgjson
With all due warning of contrived benchmarks, I wrote some tests to see
where things stand. The test script is here:
https://github.com/tlaurenzo/pgjson/blob/master/testdocs/runbench
Thanks for your concerns about my question. I am really happy to get the
answers.
@Mr. Tom Lane: Thanks for your explanation but I am already using Eclipse
which gets me to the definitions real easy. I do not post my questions on
the Hackers forum with any intention to disturb anyone. I just ask f
On Sat, Nov 20, 2010 at 11:22 PM, Robert Haas wrote:
> On Thu, Nov 4, 2010 at 3:39 PM, Dimitri Fontaine
> wrote:
>> Tom Lane writes:
>>> Not having read the patch, but ... the idea that was in the back of
>>> my mind was to have a generic AlterObjectNamespace function that
>>> would take parame
On Thu, Nov 4, 2010 at 3:39 PM, Dimitri Fontaine wrote:
> Tom Lane writes:
>> Not having read the patch, but ... the idea that was in the back of
>> my mind was to have a generic AlterObjectNamespace function that
>> would take parameters approximately like the following:
>
> Please find attached
On Sat, Nov 20, 2010 at 7:29 AM, Pavel Stehule wrote:
> 2010/11/20 Robert Haas :
>> On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule
>> wrote:
>>> I think so you are a correct. Who will a submit this final version? You or
>>> me?
>>
>> I've got it.
>>
>
> Thank you
>
> nice a day
OK, I've commit
On Sat, Nov 20, 2010 at 01:54:32PM +0900, Itagaki Takahiro wrote:
> On Sat, Nov 20, 2010 at 03:48, wrote:
> > Note the standard also supports unnesting multiple arrays concurrently, the
> > rule for handling arrays with different lengths is to use null padding of
> > the shorter array.
> >
> >
On Sat, Nov 20, 2010 at 5:17 PM, Robert Haas wrote:
> On Sat, Nov 20, 2010 at 6:21 PM, Jeff Janes wrote:
>>> Doing all the writes and then all the fsyncs meets this requirement
>>> trivially, but I'm not so sure that's a good idea. For example, given
>>> files F1 ... Fn with dirty pages needing
On Sat, Nov 20, 2010 at 6:21 PM, Jeff Janes wrote:
>>> The thing to realize
>>> that complicates the design is that the actual sync execution may take a
>>> considerable period of time. It's much more likely for that to happen than
>>> in the case of an individual write, as the current spread che
On Sat, Nov 20, 2010 at 9:07 PM, Tom Lane wrote:
> In practice we do not need to worry about changes made with a kernel
> call in between, as any sort of context swap will cause the kernel to
> force cache synchronization.
>
Note that not all kernel calls are equal these days. Some
(gettimeofday
2010/11/12 Teodor Sigaev :
>> Slightly-more-fleshed out proof of concept patch attached, with actual
>> syntax, documentation, and pg_dump support added. This might be
>> thought of as a subset of the builtin_knngist_core patch, without the
>> parts that make it actually do something useful (which
On Mon, Nov 15, 2010 at 6:15 PM, Robert Haas wrote:
> On Sun, Nov 14, 2010 at 6:48 PM, Greg Smith wrote:
>> The second issue is that the delay between sync calls is currently
>> hard-coded, at 3 seconds. I believe the right path here is to consider the
>> current checkpoint_completion_target to
Tom Lane wrote:
> Bruce Momjian writes:
> > I assume you are suggesting to use our inet_net_ntop() even if the
> > system has inet_ntop().
>
> If you're going to have code to do the former, it doesn't seem to be
> worth the trouble to also have code that does the latter ...
OK, we will not call
Tom Lane writes:
> Here's my single biggest tip for newcomers to the Postgres source:
> if you don't use ctags, glimpse, or some other tool that can quickly
> show you all references to a given identifier, go out and get one.
> It's one of the easiest ways to learn about things.
I've been using c
Bruce Momjian writes:
> I assume you are suggesting to use our inet_net_ntop() even if the
> system has inet_ntop().
If you're going to have code to do the former, it doesn't seem to be
worth the trouble to also have code that does the latter ...
regards, tom lane
--
Se
On 2010-11-20 21:57, Yeb Havinga wrote:8K blocksize:
postgres=# create index seg_test_idx on seg_test using gist (a);
CREATE INDEX
Time: 99613.308 ms
SELECT
Total runtime: 81.482 ms
1K blocksize:
CREATE INDEX
Time: 40113.252 ms
SELECT
Total runtime: 3.363 ms
Details of explain analyze are below
Robert Haas writes:
> So what DO we need to guard against here?
I think the general problem can be stated as "process A changes two or
more values in shared memory in a fairly short span of time, and process
B, which is concurrently examining the same variables, sees those
changes occur in a diff
On 2010-11-20 13:36, Yeb Havinga wrote:
On 2010-11-20 04:46, Robert Haas wrote:
Well, the problem with just comparing on< is that it takes very
little account of the upper bounds. I think the cases where a simple
split would hurt you the most are those where examining the upper
bound is necess
Some additional comments ...
Robert Haas writes:
> With regards to your question, for each type of plan node, there is an
> associated "plan state" node. This is an important distinction
> because, IIUC, plans can be reused, so plan state contains the
> information that might need to be reset on
Tom Lane wrote:
> Bruce Momjian writes:
> > I was wondering that. I am unclear if we need it though --- can we not
> > assume inet_ntop() exists on all systems? We assumed inet_ntoa() did.
>
> The Single Unix Spec includes inet_ntoa but not inet_ntop.
>
> > Of course, the buildfarm will tell
Greg Stark writes:
> On Sat, Nov 20, 2010 at 6:31 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I had given some thought to whether it might make sense to try to
>>> figure out how long the string will be before we actually start
>>> generating it, so that we can just start in the exactly right
On Sat, Nov 20, 2010 at 6:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane wrote:
>>> what about building it working backwards from the end of the buffer
>>> and then memmove'ing it down to the start of the buffer?
>
>> I think that might be more clever
On Saturday 20 November 2010 18:18:32 Robert Haas wrote:
> > Likewise for the int64 case, which BTW is no safer for pre-C99 compilers
> > than it was yesterday: LL is not the portable way to write int64
> > constants.
> Gah. I wish we had some documentation of this stuff.
Dito. I started doing Cis
On Saturday 20 November 2010 18:34:04 Tom Lane wrote:
> BTW, while we're thinking about marginal improvements: instead of
> constructing the string backwards and then reversing it in-place,
> what about building it working backwards from the end of the buffer
> and then memmove'ing it down to the s
I sure do respect that. Appreciated. :)
-Vaibhav (*_*)
On Sun, Nov 21, 2010 at 12:33 AM, Robert Haas wrote:
> On Sat, Nov 20, 2010 at 1:59 PM, Vaibhav Kaushal
> wrote:
> > Thanks a lot for the answer. I see a lot of people discussing so many
> things
> > so I thought my email would have been i
On Fri, Nov 19, 2010 at 5:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> But what about timings vs. random other stuff? Like in this case
>> there's a problem if the signal arrives before the memory update to
>> latch->is_set becomes visible. I don't know what we need to do to
>> guarantee tha
On Sat, Nov 20, 2010 at 1:59 PM, Vaibhav Kaushal
wrote:
> Thanks a lot for the answer. I see a lot of people discussing so many things
> so I thought my email would have been ignored by those with a lot coming in
> already. Thanks for the enlightenment.
Sure. Just FYI, with these kinds of things
Thanks a lot for the answer. I see a lot of people discussing so many things
so I thought my email would have been ignored by those with a lot coming in
already. Thanks for the enlightenment.
-Vaibhav (*_*)
On Sun, Nov 21, 2010 at 12:25 AM, Robert Haas wrote:
> On Fri, Nov 19, 2010 at 10:51 PM
On Sat, Nov 20, 2010 at 1:51 PM, Tom Lane wrote:
>> If it's all right with you, I'll go ahead and commit this and then you
>> can break as much more stuff as you like. :-)
>
> Go for it.
Your turn.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
On Fri, Nov 19, 2010 at 10:51 PM, Vaibhav Kaushal
wrote:
> Is no one ready to help on this? :(
Apparently, no one is ready to drop what they are doing to immediately
answer your email before all the other ones they need to answer, but I
wouldn't infer from that that no one wants to help. It does
Robert Haas writes:
> On Sat, Nov 20, 2010 at 1:37 PM, Tom Lane wrote:
>> I think your revised patch is incorrect, or at least not terribly safe,
>> to just remove the last DoneMatchingIndexKeys test and not replace it
>> with anything else.
Oh, now that I look at it I notice the after-the-fact
On Sat, Nov 20, 2010 at 1:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane wrote:
>>> But if you're going to do that, get rid of DoneMatchingIndexKeys
>>> altogether,
>
>> Sure. That's a giant crock.
>
>>> along with the extra zero that plancat.c adds to
Robert Haas writes:
> On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane wrote:
>> But if you're going to do that, get rid of DoneMatchingIndexKeys
>> altogether,
> Sure. That's a giant crock.
>> along with the extra zero that plancat.c adds to the
>> opfamily array. We don't need to be using more tha
On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> I was looking at KNNGIST some more today and found myself trying to
>> disentangle what match_clause_to_indexcol() is actually doing. It
>> appears to me that the opfamily passed to that function is always the
>> same as i
Robert Haas writes:
> On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane wrote:
>> what about building it working backwards from the end of the buffer
>> and then memmove'ing it down to the start of the buffer?
> I think that might be more clever than is really warranted. I get
> your point about buffe
On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane wrote:
> BTW, while we're thinking about marginal improvements: instead of
> constructing the string backwards and then reversing it in-place,
> what about building it working backwards from the end of the buffer
> and then memmove'ing it down to the star
Robert Haas writes:
> I was looking at KNNGIST some more today and found myself trying to
> disentangle what match_clause_to_indexcol() is actually doing. It
> appears to me that the opfamily passed to that function is always the
> same as index->opfamily[indexcol], which seems like needless
> no
I was looking at KNNGIST some more today and found myself trying to
disentangle what match_clause_to_indexcol() is actually doing. It
appears to me that the opfamily passed to that function is always the
same as index->opfamily[indexcol], which seems like needless
notational complexity. Maybe I'm
BTW, while we're thinking about marginal improvements: instead of
constructing the string backwards and then reversing it in-place,
what about building it working backwards from the end of the buffer
and then memmove'ing it down to the start of the buffer?
I haven't tested this but it seems likely
On Sat, Nov 20, 2010 at 10:38 AM, Tom Lane wrote:
> The trouble with that approach is that you have to depend on the
> direction of rounding for negative quotients. Which was unspecified
> before C99, and it's precisely pre-C99 compilers that are posing a
> hazard to the current coding.
Interest
Robert Haas writes:
> It occurs to me belatedly that there might be a better way to do this.
> Instead of flipping value from negative to positive, with a special
> case for the smallest possible integer, we could do it the other
> round. And actually, I think we can rid of neg, too.
The troubl
On Sat, Nov 20, 2010 at 6:46 AM, Robert Haas wrote:
> Well, the problem with just comparing on < is that it takes very
> little account of the upper bounds. I think the cases where a simple
> split would hurt you the most are those where examining the upper
> bound is necessary to to get a good
On 2010-11-20 04:46, Robert Haas wrote:
On Tue, Nov 16, 2010 at 6:07 AM, Alexander Korotkov
wrote:
On Tue, Nov 16, 2010 at 3:07 AM, Robert Haas wrote:
But on a broader note, I'm not very certain the sorting algorithm is
sensible. For example, suppose you have 10 segments that are exactly
'0
2010/11/20 Robert Haas :
> On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule
> wrote:
>> I think so you are a correct. Who will a submit this final version? You or
>> me?
>
> I've got it.
>
Thank you
nice a day
Pavel
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterpris
On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule wrote:
> I think so you are a correct. Who will a submit this final version? You or me?
I've got it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Fri, Nov 19, 2010 at 10:18 PM, Robert Haas wrote:
> Sure thing. Thanks for taking time to do this - very nice speedup.
> This part now committed, too.
It occurs to me belatedly that there might be a better way to do this.
Instead of flipping value from negative to positive, with a special
ca
Hello
2010/11/20 Jeff Janes :
> On Thu, Nov 18, 2010 at 11:54 PM, Pavel Stehule
> wrote:
>> -- Forwarded message --
>> From: Pavel Stehule
>> Date: 2010/11/18
>> Subject: Re: patch: format function, next generation
>> To: Jeff Janes
>> Kopie: pgsql-hackers-ow...@postgresql.org
47 matches
Mail list logo
