reducejoins.c ?
flattenjoins.c ?
filterjoins.c ?
--
dim
Le 28 mars 2010 à 22:12, Tom Lane a écrit :
Robert Haas writes:
On Sun, Mar 28, 2010 at 2:10 PM, Tom Lane wrote:
joinremoval.c ?
Maybe, except as I mentioned in the email linked upthread, my plan
for
implementing inner join r
David Christensen wrote:
Enclosed is a patch to add a -C option to initdb to allow you to easily append
configuration directives to the generated postgresql.conf file for use in
programmatic generation.
We had a patch not quite make it for 9.0 that switched over the
postgresql.conf file to m
David Christensen wrote:
> Enclosed is a patch to add a -C option to initdb to allow you to easily
> append configuration directives to the generated postgresql.conf file
Why don't you use just "echo 'options' >> $PGDATA/postgresql.conf" ?
Could you explain where the -C options is better than i
Hackers,
Enclosed is a patch to add a -C option to initdb to allow you to easily append
configuration directives to the generated postgresql.conf file for use in
programmatic generation. In my case, I'd been creating multiple db clusters
with a script and would have specific overrides that I n
2010/3/29 Andrew Dunstan :
> Robert Haas wrote:
>> On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
>> wrote:
>>> I'm wondering whether the internal representation of JSON should be
>>> plain JSON text, or some binary code that's easier to traverse and
>>> whatnot. For the sake of code size, just ke
On Sun, Mar 28, 2010 at 11:24 PM, Joseph Adams
wrote:
> I apologize; I was just starting the conversation with some of my
> ideas to receive feedback. I didn't want people to have to wade
> through too many "I think"s . I'll be sure to use tags in
> the future :-)
FWIW, I don't care at all whe
On Sun, Mar 28, 2010 at 5:19 PM, Robert Haas wrote:
> On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
> wrote:
>> Now my thoughts and opinions on the JSON parsing/unparsing itself:
>>
>> It should be built-in, rather than relying on an external library
>> (like XML does).
>
> Why? I'm not saying y
On Sun, Mar 28, 2010 at 10:01 PM, gaurav gupta
wrote:
> My idea is to add a functionality of Auto tuning and Auto Indexing/
> Reindexing in DB languages.
>
> Though I am not working on this I have some idea about implementation.
> Idea is that on the no. of rows deleted, Inserted in the table we c
Sir/Ma'am,
I am a Mtech student and want to participate in GSoC. I have a project
idea and want to discuss its feasibility, usability and chance of selection
with you.
My idea is to add a functionality of Auto tuning and Auto Indexing/
Reindexing in DB languages.
Though I am not working on t
On Sun, Mar 28, 2010 at 8:33 PM, Robert Haas wrote:
> On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander wrote:
>> In practice, every parser/serializer I've used (including the one I
>> helped write) allows (and, often, forces) any non-ASCII character to
>> be encoded as \u followed by a string of fo
Andrew Dunstan wrote:
Robert Haas wrote:
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander
wrote:
In practice, every parser/serializer I've used (including the one I
helped write) allows (and, often, forces) any non-ASCII character to
be encoded as \u followed by a string of four hex digits
Robert Haas wrote:
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander wrote:
In practice, every parser/serializer I've used (including the one I
helped write) allows (and, often, forces) any non-ASCII character to
be encoded as \u followed by a string of four hex digits.
Is it correct t
On Sun, Mar 28, 2010 at 8:23 PM, Mike Rylander wrote:
> In practice, every parser/serializer I've used (including the one I
> helped write) allows (and, often, forces) any non-ASCII character to
> be encoded as \u followed by a string of four hex digits.
Is it correct to say that the only feasibl
On Sun, Mar 28, 2010 at 7:36 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Here's another thought. Given that JSON is actually specified to consist
>> of a string of Unicode characters, what will we deliver to the client
>> where the client encoding is, say Latin1? Will it actually be a legal
>
On Sun, Mar 28, 2010 at 7:36 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Here's another thought. Given that JSON is actually specified to consist
>> of a string of Unicode characters, what will we deliver to the client
>> where the client encoding is, say Latin1? Will it actually be a legal
>
Andrew Dunstan writes:
> Here's another thought. Given that JSON is actually specified to consist
> of a string of Unicode characters, what will we deliver to the client
> where the client encoding is, say Latin1? Will it actually be a legal
> JSON byte stream?
No, it won't. We will *not* be
Tom Lane wrote:
Andrew Dunstan writes:
Robert Haas wrote:
I think you need to assume that the encoding will be the server
encoding, not UTF-8. Although others on this list are better
qualified to speak to that than I am.
The trouble is that JSON is defined to be specific
On Sun, Mar 28, 2010 at 4:40 PM, Josh Berkus wrote:
> We've got two locations and some individuals signed up for a test-fest
> this weekend. Would it be possible to do an alpha release this week?
> It would really help to be testing later code than Alpha4.
I'm willing to do the CVS bits, if that
Andrew Dunstan writes:
> Robert Haas wrote:
>> I think you need to assume that the encoding will be the server
>> encoding, not UTF-8. Although others on this list are better
>> qualified to speak to that than I am.
> The trouble is that JSON is defined to be specifically Unicode, and in
> prac
Per previous discussion, PFA a patch to change the maximum number of
keys for a syscache from 4 to 5.
http://archives.postgresql.org/pgsql-hackers/2010-02/msg01105.php
This is intended for application to 9.1, and is supporting
infrastructure for knngist.
...Robert
syscache5.patch
Description:
Robert Haas wrote:
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
wrote:
I'm wondering whether the internal representation of JSON should be
plain JSON text, or some binary code that's easier to traverse and
whatnot. For the sake of code size, just keeping it in text is
probably best.
On Sun, Mar 28, 2010 at 4:48 PM, Joseph Adams
wrote:
> I'm wondering whether the internal representation of JSON should be
> plain JSON text, or some binary code that's easier to traverse and
> whatnot. For the sake of code size, just keeping it in text is
> probably best.
+1 for text.
> Now my
On Sun, Mar 28, 2010 at 4:12 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 28, 2010 at 2:10 PM, Tom Lane wrote:
>>> joinremoval.c ?
>
>> Maybe, except as I mentioned in the email linked upthread, my plan for
>> implementing inner join removal would also include allowing join
>> reorde
I introduced myself in the thread "Proposal: access control jails (and
introduction as aspiring GSoC student)", and we discussed jails and
session-local variables. But, as Robert Haas suggested, implementing
variable support in the backend would probably be way too ambitious a
project for a newbie
All,
We've got two locations and some individuals signed up for a test-fest
this weekend. Would it be possible to do an alpha release this week?
It would really help to be testing later code than Alpha4.
--
-- Josh Berkus
Po
Robert Haas writes:
> On Sun, Mar 28, 2010 at 2:10 PM, Tom Lane wrote:
>> joinremoval.c ?
> Maybe, except as I mentioned in the email linked upthread, my plan for
> implementing inner join removal would also include allowing join
> reordering in cases where we currently don't. So I don't want t
On Sun, Mar 28, 2010 at 2:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 28, 2010 at 2:04 PM, Tom Lane wrote:
>>> * in a new file in plan/. Not sure if it's worth this, though your
>>> thought that we might add more logic later makes it more defensible.
>
>> I sort of like the last
Robert Haas writes:
> On Sun, Mar 28, 2010 at 2:04 PM, Tom Lane wrote:
>> * in a new file in plan/. Not sure if it's worth this, though your
>> thought that we might add more logic later makes it more defensible.
> I sort of like the last of these ideas though I'm at a loss for what
> to call i
On Sun, Mar 28, 2010 at 2:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Mar 28, 2010 at 12:19 AM, Tom Lane wrote:
>>> * I left join_is_removable where it was, mainly so that it was easy to
>>> compare how much it changed for this usage (not a lot). I'm not sure
>>> that joinpath.c is
Robert Haas writes:
> On Sun, Mar 28, 2010 at 12:19 AM, Tom Lane wrote:
>> * I left join_is_removable where it was, mainly so that it was easy to
>> compare how much it changed for this usage (not a lot). I'm not sure
>> that joinpath.c is an appropriate place for it anymore, though I can't
>> s
I wrote:
> Robert Haas writes:
>> I'm alarmed by your follow-on statement that the current code can't
>> handle the two-levels of removable join case. Seems like it ought to
>> form {B C} as a path over {B} and then {A B C} as a path over {A}.
> Actually I think it ought to form {A B} as a no-op
Simon Riggs writes:
> On Fri, 2010-03-26 at 18:59 +, Greg Stark wrote:
>> It occurs to me we could do the same for CHECK_FOR_INTERRUPTS() by
>> conditionally having it call a function which calls gettimeofday and
>> compares with the previous timestamp received at the last CFI().
> Reducing l
Simon Riggs writes:
> Does the new patch find more than two levels of join removal?
Well, I'd assume if it can do two nested levels then it should work for
any number, but I plead guilty to not having actually tested that.
regards, tom lane
--
Sent via pgsql-hackers mai
On Fri, 2010-03-26 at 18:59 +, Greg Stark wrote:
> The Linux kernel had a big push to reduce latency, and one of the
> tricks they did was they replaced the usual interrupt points with a
> call which noted how long it had been since the last interrupt point.
> It occurs to me we could do the s
On Sun, 2010-03-28 at 02:15 -0400, Tom Lane wrote:
> I wrote:
> > [ crude patch ]
>
> Oh, btw, if you try to run the regression test additions in that patch
> against CVS HEAD, you'll find out that HEAD actually fails to optimize
> the two-levels-of-removable-joins case. Seems like another reason
Robert Haas writes:
> I'm alarmed by your follow-on statement that the current code can't
> handle the two-levels of removable join case. Seems like it ought to
> form {B C} as a path over {B} and then {A B C} as a path over {A}.
Actually I think it ought to form {A B} as a no-op join and then b
On Sun, Mar 28, 2010 at 12:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Mar 27, 2010 at 4:11 PM, Tom Lane wrote:
>>> I'm not seeing how that would occur or would matter, but the worst case
>>> answer is to restart the scan of the SpecialJoinInfos from scratch any
>>> time you succeed
On Sat, 2010-03-27 at 22:39 +, Greg Stark wrote:
> On Sat, Mar 27, 2010 at 7:36 PM, Simon Riggs wrote:
> > On Sat, 2010-03-27 at 19:15 +, Greg Stark wrote:
> > > If we're pruning an index entry to a heap tuple that has been HOT
> > > pruned wouldn't the HOT pruning record have already conf
38 matches
Mail list logo
