Kevin,
It would be hard to schedule the requisite time on our biggest web
machines, but I assume an 8 core 64GB machine would give meaningful
results. Any sense what numbers of parallel jobs I should use for
tests? I would be tempted to try 1 (with the -1 switch), 8, 12, and
16 -- maybe keep g
Hi,
> Nikhil,
>
> This is still flagged as Needs Review. Are you still reviewing the
> latest version, or should this be set to ready for committer, or what?
>
The review is complete from my side. There is this question about
consistency between this patch and the Defaultacls patch. But am ok
wi
Rather than testing single bits in a loop, change AllocSetFreeIndex to
use the __builtin_clz() function to calculate the chunk index.
This requires a new check for __builtin_clz in the configure script.
Results in a ~2% performance increase on sysbench on PowerPC.
Signed-off-by: Jeremy Kerr
--
Robert Haas writes:
> On Sun, Jul 19, 2009 at 10:56 PM, Tom Lane wrote:
>> I think we want something along the lines of relation_is_distinct_for
>> with a list of columns and a list of comparison operators, where the
>> first-cut implementation will be to look for matching indexes.
> That seems r
On Sun, Jul 19, 2009 at 10:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 16, 2009 at 9:02 PM, Greg Stark wrote:
>>> I have one big worry though. Currently you're detecting the unique
>>> property using the planner's path mechanism. I suppose that works, but
>>> it's only an accident
Alvaro Herrera writes:
> Kevin Grittner wrote:
>> Bingo! A few weeks back I had been experimenting with using the PGXS
>> compiles for our extensions, rather than expanding our tarballs in the
>> build tree and just doing make and sudo make install there. On the
>> failing machine, the session I
Bruce Momjian writes:
> I thought we wanted psql to be able to connect to older databases and
> report \d values properly. I see 8.4 psql \d is not working for
> sequences in 8.3 databases:
Fixed ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacke
Kevin Grittner wrote:
> Andrew Dunstan wrote:
>
> > That's why I asked to see the make log. Maybe some environment
> > setting affected things?
>
> Bingo! A few weeks back I had been experimenting with using the PGXS
> compiles for our extensions, rather than expanding our tarballs in the
> b
Dean Rasheed wrote:
> Thanks for the thorough review. I attach an new version of the patch,
> updated to HEAD, and with the index AM change discussed.
Wow, this is a large patch.
I didn't do a thorough review, but some quickies I noticed:
* Please move the code that says that it should be in a n
Robert Haas writes:
> On Thu, Jul 16, 2009 at 9:02 PM, Greg Stark wrote:
>> I have one big worry though. Currently you're detecting the unique
>> property using the planner's path mechanism. I suppose that works, but
>> it's only an accident of the planner design that the path for the
>> unique in
Bernd Helmle wrote:
Here is a slightly updated version of the patch. I did some (very
minor) editing on the wording in the docs and cleaned a merge conflict
in tablecmds.c. I saw no code issues so far, make check passes without
errors. Maybe someone with more bison skills can comment on the
Jeremy Kerr writes:
> We also need disable_sigpipe to be called when it's not the start of a
> block, hence the separate type definition.
So break that macro into two (variable definition and code).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Jeremy Kerr writes:
>>> - inline is forbidden to use in PostgreSQL - you need exception or
>>> do it differently
> (inline again: should I just make this a static, the compiler can inline
> where possible? or do you want a macro?)
I don't know where Zdenek got the idea that we have something ag
Robert Haas wrote:
Quite beyond the fact that we never seem to be able to get a patch
that implements a reasonable first set of features, the amount of work
that's going to be required to get these patches committable is going
to be enormous. Just to cite a few examples, here is the
documentatio
Tom,
> However, I think the whole patch is pretty useless. That code is not
> broken as it stands, and doesn't appear to really gain anything from
> the proposed change. Why should we risk any portability questions
> when the code isn't going to get either simpler or shorter?
This patch "clears
Alvaro Herrera wrote:
Peter Eisentraut wrote:
On Friday 17 July 2009 15:58:27 Richard Huxton wrote:
1. Fixed navigation
2. Titles on navigation links.
Yes, the DSSSL stylesheet could do that.
Since it seems we can get both of these without interfering with
Hi Robert,
> That having been said, Jeremy, you probably want to take a look at
> those comments and I have a few responses to them as well.
OK, thanks for the heads-up.
> following comment:
> > Applied and built cleanly. Regress passes. Trying to hunt down ppc
> > box to see if performance enha
Jeremy Kerr writes:
> However, I'd rather make decisions on data, rather than guessing. Is the
> actual problem here that some compilers just don't support the 'inline'
> keyword?
I think Alvaro's complaint is unfounded --- we already have logic
to #define inline as empty if the compiler doesn'
Hi Robert,
> Perhaps we should use macros.
I was trying to avoid macros, as this means we lose type- and syntax-
checking at the call-site, and end up with slightly messier code.
However, I understand that this is probably personal preference for me
:)
How about just 'static' functions? (ie,
Robert Haas wrote:
On Sat, Jul 18, 2009 at 7:10 AM, Martijn van
Oosterhout wrote:
On Fri, Jul 17, 2009 at 03:59:29PM +0300, Peter Eisentraut wrote:
I'm starting to think that there's just no hope of this matching up
well enough with the way PostgreSQL already works to have a chance of
being acc
Peter Eisentraut wrote:
> On Friday 17 July 2009 15:58:27 Richard Huxton wrote:
> > 1. Fixed navigation
> > 2. Titles on navigation links.
>
> Yes, the DSSSL stylesheet could do that.
Since it seems we can get both of these without interfering with
anything else I vote +1 on getting them it.
>
On Fri, Jul 17, 2009 at 9:16 AM, Petr Jelinek wrote:
> One more typo fix in docs
>
>
> --
> Regards
> Petr Jelinek (PJMODOS)
Nikhil,
This is still flagged as Needs Review. Are you still reviewing the
latest version, or should this be set to ready for committer, or what?
...Robert
--
Sent via
On Sun, Jul 19, 2009 at 9:47 AM, Andres Freund wrote:
> On Sunday 19 July 2009 14:39:33 Martijn van Oosterhout wrote:
>> On Sun, Jul 19, 2009 at 03:15:38AM +0200, Andres Freund wrote:
>> > Hi Robert, Hi All,
>> >
>> > Patch applies with some offset changes, code changes look sensible, I
>> > person
I thought we wanted psql to be able to connect to older databases and
report \d values properly. I see 8.4 psql \d is not working for
sequences in 8.3 databases:
$ psql regression
psql (8.4.0, server 8.3.7)
WARNING: psql version 8.4, server version 8.3.
So
Robert Haas writes:
> Tom, do you think the "independent subproblem" stuff from last night
> would be worth pursuing?
It's worth looking into. I'm not certain if it will end up being a good
idea or not. Right now the joinlist collapse code is pretty stupid
(as you know --- it only thinks about
On Sun, Jul 19, 2009 at 1:23 PM, Tom Lane wrote:
> My conclusions are:
>
> 1. I should clean up and apply the attached patch. Even though it's
> not the whole answer, it clearly makes things a good deal better.
>
> 2. We need to look into a more efficient representation for making
> have_relevant
On Sun, Jul 19, 2009 at 12:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think this is a great feature, and it would be REALLY great if it
>> supported UPDATE and DELETE as well.
>
> It won't get applied until it does, and I imagine the patch author
> wasn't expecting any differently. The sub
On Sun, Jul 19, 2009 at 8:53 AM, Dimitri Fontaine wrote:
> Oh and I see that "Returned with feedback" did set a "Close Date", so it's
> not what I intended anyway. I've changed the status to "Waiting on Author"
> and if we have no news before the end of current commit fest, I'll then move
> it to "
Andres Freund writes:
> On Saturday 18 July 2009 17:48:14 Tom Lane wrote:
>> I'm inclined to address this by rewriting gimme_tree so that it *always*
>> finds a valid join order based on the given tour. This would involve
>> searching the whole stack for a possible join partner instead of
>> cons
On Sun, Jul 19, 2009 at 10:13:35PM +0800, Xin Wang wrote:
> My research project is based on PostgreSQL. I want to get the
> Post-Schema-Validation-Infoset (PSVI) of an XML document being
> stored. However, the current libxml2 library does not support PSVI at
> all. So I have to use the Xerces C
Robert Haas writes:
> I think this is a great feature, and it would be REALLY great if it
> supported UPDATE and DELETE as well.
It won't get applied until it does, and I imagine the patch author
wasn't expecting any differently. The submission was clearly marked
"WIP" not "ready to apply".
> H
Hello,
while writing some basic docs I found bug in dependency handling when
doing SET on object type that already had some default privileges.
Attached patch fixes it, it also fixes thinko in parser (DROPing GRANT
OPTION behaves like REVOKE now). And there is also initial version of
those ba
Joe Conway wrote:
> If I click on the link for patch, I go to here:
> http://archives.postgresql.org/message-id/162867790905270504m6bb30e2eqa5021e0d60a43...@mail.gmail.com
>
> Is there a way for me to extract the patch as the original attachment,
> or am I supposed to just cat-n-paste into an edi
Hi all,
My research project is based on PostgreSQL. I want to get the
Post-Schema-Validation-Infoset (PSVI)
of an XML document being stored. However, the current libxml2 library does
not support PSVI at all. So
I have to use the Xerces C++ library in PostgreSQL. But I wonder if it is
possible t
On Sunday 19 July 2009 14:39:33 Martijn van Oosterhout wrote:
> On Sun, Jul 19, 2009 at 03:15:38AM +0200, Andres Freund wrote:
> > Hi Robert, Hi All,
> >
> > Patch applies with some offset changes, code changes look sensible, I
> > personally like the new syntax and the features it may allow in fut
Robert Haas wrote:
On Sat, Jul 18, 2009 at 4:41 PM, Kevin
Grittner wrote:
"Kevin Grittner" wrote:
Performance tests to follow in a day or two.
I'm looking to beg another week or so on this to run more tests. What
I can have by the end of today is pretty limited, mostly beca
Robert Haas wrote:
On Tue, Jun 30, 2009 at 3:08 AM, Jeremy Kerr wrote:
Move the shift-and-test login into a separate fls() function, which
can use __builtin_clz() if it's available.
This requires a new check for __builtin_clz in the configure script.
Results in a ~2% performance increase on Po
Kevin Grittner wrote:
"Kevin Grittner" wrote:
Performance tests to follow in a day or two.
I'm looking to beg another week or so on this to run more tests. What
I can have by the end of today is pretty limited, mostly because I
decided it made the most sense to test this with big complex
Jaime Casanova wrote:
- why you need a node InsertReturning (see nodeInsertReturning.c) at all?
I couldn't come up with a better way to do this.
and it crashes for triggers (example using regression's int4_tbl)
Right. I never tested this with triggers. The trigger tuple slot isn't
al
Hi,
Le 19 juil. 09 à 06:30, Robert Haas a écrit :
On Sat, Jul 18, 2009 at 5:28 PM, Tom Lane wrote:
What do you want to use then ... Waiting on Author?
Yeah, that's what I was thinking.
Oh and I see that "Returned with feedback" did set a "Close Date", so
it's not what I intended anyway. I
On Sun, Jul 19, 2009 at 03:15:38AM +0200, Andres Freund wrote:
> Hi Robert, Hi All,
>
> Patch applies with some offset changes, code changes look sensible, I
> personally like the new syntax and the features it may allow in future. One,
> possibly big, gripe remains though:
> The formerly valid
On Sat, Jul 18, 2009 at 6:14 AM, Dimitri Fontaine wrote:
> Le 17 juil. 09 à 23:24, Tom Lane a écrit :
>>
>> It seems unlikely that the DB version number would be worth the prompt
>> space. In situations like that you'd much more likely need identifying
>> info like the DB hostname and port number.
On Jul 18, 2009, at 3:40 PM, Greg Stark wrote:
On Sat, Jul 18, 2009 at 8:25 PM, Robert Haas
wrote:
On Thu, Jul 9, 2009 at 4:51 AM, Itagaki
Takahiro wrote:
Here is an updated version of multi-threaded pgbench patch.
Greg (Smith), do you have time to review this version? If not, I
will
a
On Sat, Jul 18, 2009 at 4:41 PM, Kevin
Grittner wrote:
> "Kevin Grittner" wrote:
>
>> Performance tests to follow in a day or two.
>
> I'm looking to beg another week or so on this to run more tests. What
> I can have by the end of today is pretty limited, mostly because I
> decided it made the m
On Tue, Jun 30, 2009 at 3:08 AM, Jeremy Kerr wrote:
> Move the shift-and-test login into a separate fls() function, which
> can use __builtin_clz() if it's available.
>
> This requires a new check for __builtin_clz in the configure script.
>
> Results in a ~2% performance increase on PowerPC.
Ther
On Sat, Jul 18, 2009 at 5:21 PM, Jaime
Casanova wrote:
> On Tue, Jul 7, 2009 at 3:31 PM, Marko Tiikkaja
> wrote:
>> [...] rules and default values don't work.
>> Recursive CTEs don't work either.
[...]
> and it crashes for triggers
I think this is a great feature, and it would be REALLY great if
On Sun, Jul 19, 2009 at 12:50 AM, Josh Berkus wrote:
>> Greg (Smith), do you have time to review this version? If not, I will
>> assign a round-robin reviewer when one becomes available.
>
> I can do a concurrency test of this next week.
Sounds good.
...Robert
--
Sent via pgsql-hackers mailing
Hi Robert, Hi All,
On Sunday 19 July 2009 04:29:42 Andres Freund wrote:
> I did not yet look at the contrib/autoexplain portions. Will do that on
> Monday or so.
Early Monday:
Looks fine, except that the new "auto_explain.log_format" parameter is not
documented.
Andres
--
Sent via pgsql-hacker
On Friday 17 July 2009 18:26:31 Fernando Ike wrote:
>Follow new version patch, now with version postgresql version.
1) This is obviously wrong:
CASE WHEN l.lanispl = 't' THEN 'Trusted' WHEN l.lanispl = 'f' THEN 'Untrusted'
END
2) It may be better to use lanispl to determine whether a langua
49 matches
Mail list logo
