Hello
2010/11/20 Jeff Janes jeff.ja...@gmail.com:
On Thu, Nov 18, 2010 at 11:54 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
-- Forwarded message --
From: Pavel Stehule pavel.steh...@gmail.com
Date: 2010/11/18
Subject: Re: patch: format function, next generation
To:
On Fri, Nov 19, 2010 at 10:18 PM, Robert Haas robertmh...@gmail.com 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
On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule pavel.steh...@gmail.com 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
2010/11/20 Robert Haas robertmh...@gmail.com:
On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule pavel.steh...@gmail.com
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:
On 2010-11-20 04:46, Robert Haas wrote:
On Tue, Nov 16, 2010 at 6:07 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Tue, Nov 16, 2010 at 3:07 AM, Robert Haasrobertmh...@gmail.com wrote:
But on a broader note, I'm not very certain the sorting algorithm is
sensible. For example,
On Sat, Nov 20, 2010 at 6:46 AM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Sat, Nov 20, 2010 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us 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
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
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
Robert Haas robertmh...@gmail.com 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
On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Nov 20, 2010 at 1:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 1:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But if you're going to do that, get rid of DoneMatchingIndexKeys
altogether,
Sure. That's a giant crock.
along
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 1:37 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Nov 19, 2010 at 10:51 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com 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
On Sat, Nov 20, 2010 at 1:51 PM, Tom Lane t...@sss.pgh.pa.us 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
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 robertmh...@gmail.com wrote:
On Fri, Nov
On Sat, Nov 20, 2010 at 1:59 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com 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,
On Fri, Nov 19, 2010 at 5:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
I sure do respect that. Appreciated. :)
-Vaibhav (*_*)
On Sun, Nov 21, 2010 at 12:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 20, 2010 at 1:59 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Thanks a lot for the answer. I see a lot of people discussing so many
things
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
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 Cish
On Sat, Nov 20, 2010 at 6:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 12:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
what about building it working backwards from the end of the buffer
and then memmove'ing it down to the start of
Greg Stark gsst...@mit.edu writes:
On Sat, Nov 20, 2010 at 6:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Some additional comments ...
Robert Haas robertmh...@gmail.com 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
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
Robert Haas robertmh...@gmail.com 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
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
Bruce Momjian br...@momjian.us 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 t...@sss.pgh.pa.us 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.
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Mon, Nov 15, 2010 at 6:15 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Nov 14, 2010 at 6:48 PM, Greg Smith g...@2ndquadrant.com 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
2010/11/12 Teodor Sigaev teo...@sigaev.ru:
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
On Sat, Nov 20, 2010 at 9:07 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Nov 20, 2010 at 6:21 PM, Jeff Janes jeff.ja...@gmail.com 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
On Sat, Nov 20, 2010 at 5:17 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 20, 2010 at 6:21 PM, Jeff Janes jeff.ja...@gmail.com 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
On Sat, Nov 20, 2010 at 01:54:32PM +0900, Itagaki Takahiro wrote:
On Sat, Nov 20, 2010 at 03:48, caleb.wel...@emc.com 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
On Sat, Nov 20, 2010 at 7:29 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2010/11/20 Robert Haas robertmh...@gmail.com:
On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I think so you are a correct. Who will a submit this final version? You or
me?
I've got
On Thu, Nov 4, 2010 at 3:39 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us 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
On Sat, Nov 20, 2010 at 11:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Nov 4, 2010 at 3:39 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
Tom Lane t...@sss.pgh.pa.us writes:
Not having read the patch, but ... the idea that was in the back of
my mind was to have a generic
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
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:
2010/11/21 Robert Haas robertmh...@gmail.com:
On Sat, Nov 20, 2010 at 7:29 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/11/20 Robert Haas robertmh...@gmail.com:
On Sat, Nov 20, 2010 at 2:59 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I think so you are a correct. Who will a
47 matches
Mail list logo
