On Tue, Jul 21, 2009 at 10:38 AM, Robert Haas wrote:
>
> Pavan, are you planning to respond to Alex's comments and/or update this
> patch?
>
Yes, I will. Hopefully by end of this week.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers ma
Hi,
Le 21 juil. 09 à 07:57, Itagaki Takahiro a écrit :
Oops, I must fix it. I didn't test well the default stack depth (10).
I'd better not have limitation of condition stack.
I'm glad to hear it's possible to implement without arbitrary limits :)
BTW, I hope I have enough feedbacks from rev
Dimitri Fontaine wrote:
> WARNING: condition stack overflow: 10
> So I'm going to change patch state to "Returned with Feedback" as I
> guess we'll need to talk about the issue and find a way to solve it,
> and I don't think this state prevent from getting back to the patch in
> this same
Jaime Casanova wrote:
> i think this one could be applied, just as is... there is no need for
> docs, because the issue being fixed is not documented... maybe that
> should be in doc of older releases?
Sure, it was an undocumented behavior. Should we need to add details
of this patch to documen
On Wed, Jul 15, 2009 at 11:44 PM, Alex Hunsaker wrote:
> On Mon, Dec 8, 2008 at 06:56, Pavan Deolasee wrote:
>> Here is a patch which implements this. The PD_ALL_VISIBLE flag is set if all
>> tuples in the page are visible to all transactions and there are no DEAD
>> line pointers in the page. The
"Dickson S. Guedes" wrote:
> Hi Takahiro, i'm the reviewer of your patch, and the following are my
> comments about it:
Thank you for reviewing. An updated patch is attached.
> The patch was applied totalty clean to CVS HEAD and compiled in Ubuntu
> 8.04, Ubuntu 8.10 and AIX 5.3, but faile
2009/7/20 KaiGai Kohei :
> Robert Haas wrote:
>> - row-level security
>> - complex DDL permissions
>
> Is the complex DDL permissions mean something like db_xxx:{create},
> db_xxx:{relabelfrom relabelto} and others?
> If so, I can agree to implement these checks at the later patch.
>
> However, ple
Hi Greg,
Thanks for the benchmark app, thought I'd pitch in with some ppc
results:
> clz 1.530s
> lookup table 1.720s
> float hack 4.424s
> unrolled 5.280s
> normal 5.369s
POWER5+:
clz 2.046s
lookup table 2.18
Greg Stark writes:
> Well it was a bit of a pain but I filled an array with (1/1000 scaled
> down) values and then permuted them. I also went ahead and set the
> low-order bits to random values since the lookup table based algorithm
> might be affected by it.
> The results are a bit disappointing
On Tue, Jul 21, 2009 at 12:07 AM, Tom Lane wrote:
> Greg Stark writes:
>> I also wonder if this microbenchmark is actually ok because it's
>> testing the same value over and over so any branch-prediction will
>> shine unrealistically well.
>
> Yeah, that is a good point --- and it would benefit th
Robert Haas wrote:
> I have attempted, on the relevant threads, to enumerate those problems
> as I see them. Mainly they have to do with hooks all over the code in
> strange and unmaintainable places, documentation that is written in
> poor English and is not easily understandable by people who ar
Josh Berkus wrote:
On 7/16/09 1:55 PM, Andrew Dunstan wrote:
Well, somebody had better suggest a syntax for it, preferably without
adding yet another keyword.
Actually, all that needs to happen is for NULL AS to accept '""' as a
string. Right now that produces:
ERROR: CSV quote characte
How many people are you looking for? Is there a number or are you
waiting for a good feeling?
The problem is not the number of people who like the patch, but the
number of people who are willing to refactor and maintain it. Right
now, if NEC decided to abandon Postgres, or if they decided
Greg Stark wrote:
> On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle wrote:
>> I am capable of speaking for Tresys in this matter. We are very interested
>> in this work and our US DoD customers need the capabilities that this
>> project adds (assuming row level access controls are a possibility).
>
On 7/16/09 1:55 PM, Andrew Dunstan wrote:
Well, somebody had better suggest a syntax for it, preferably without
adding yet another keyword.
Actually, all that needs to happen is for NULL AS to accept '""' as a
string. Right now that produces:
ERROR: CSV quote character must not appear in t
Greg Stark writes:
> I also wonder if this microbenchmark is actually ok because it's
> testing the same value over and over so any branch-prediction will
> shine unrealistically well.
Yeah, that is a good point --- and it would benefit the unrolled loop
more than the other versions. We should p
Itagaki-san,
On Apple OS 10.5:
1. new patch applied cleanly
2. new patch built cleanly
3. regression tests pass
4. Tested following operations:
postgres=# COPY marchlog TO '/tmp/marchlog1.csv' with csv header;
COPY 81097
postgres=# COPY marchlog TO '/tmp/marchlog2.csv' with csv header force
qu
Doh, I forgot this bit. Will rerun tests now.
On Mon, Jul 20, 2009 at 8:25 PM, Tom Lane wrote:
> (Note: I found
> out that it's necessary to split the test into two files --- otherwise
> gcc will inline AllocSetFreeIndex and partially const-fold the work,
> leading to skewed results.)
--
gre
2009/7/20 Alvaro Herrera :
> Seems related to the new list in AfterTriggerSaveEvent, which is
> used in ways that seem to conflict with its header comment ...
Reading the comment for that function, I think it is quite misleading
- mainly because the meaning of the word "event" mutates half-way
t
Jamie Fox wrote:
> > > Here's what I have found that got broken during pg_migrate: In two side
> > by
> > > side databases (an 8.3.7 copy and 8.4.0 migrated with pg_migrator) the
> > > pg_largeobject table has the same number of rows. However, in the 8.4
> > > database any select for an loid in p
On Mon, Jul 20, 2009 at 8:44 PM, Joshua Brindle wrote:
> I am capable of speaking for Tresys in this matter. We are very interested
> in this work and our US DoD customers need the capabilities that this
> project adds (assuming row level access controls are a possibility).
I'm kind of curious ab
(cc'ing Webb Sprague because I believe this was actually his
idea...don't want to take credit for it if so. :) )
On Fri, Jul 10, 2009 at 4:06 PM, Josh Berkus wrote:
> Gabrielle of PDXPUG volunteered that PUG to hold a "code sprint" in
> coordination with a commitfest sometime soon. For that event
On Mon, Jul 20, 2009 at 3:44 PM, Joshua Brindle wrote:
> Ron Mayer wrote:
>>
>> Joshua Brindle wrote:
>>>
>>> How many people are you looking for? Is there a number or are you
>>> waiting for a good feeling?
>>
>>
>
>> Joshua - if you're still associated with Tresys - could someone
>> who could sp
On Mon, Jul 20, 2009 at 8:37 PM, Tom Lane wrote:
> Anyone want to see if they can beat that? Some testing on other
> architectures would help too.
Hm, I took the three implementations so far (normal, unrolled, and
clz) as well as the two from
http://graphics.stanford.edu/~seander/bithacks.html#In
Bruce Momjian wrote:
> > After a quick chat with Bruce it was determined that we don't freeze
> > anything (it would be horrid for downtime if we did so in pg_migrator;
> > and it would be useless if ran anywhere else). What we do is migrate
> > pg_clog from the old cluster to the new. So never m
Peter Eisentraut wrote:
> On Wednesday 08 July 2009 02:09:20 Alvaro Herrera wrote:
> > It seems our makefiles fail to install fmgroids.h by "make install" in a
> > VPATH build.
>
> > I think the solution is to treat fmgroids.h just like pg_config_os.h,
> > i.e. add a line like this:
> >
> > $(
David Fetter wrote:
>
> 2. Apart from Kohei-san and Stephen Frost, is anybody actually
> interested in having this feature at all?
The features (both MAC, and row-level security), are interesting.
* I've worked with organizations where MAC was a big deal.
* I've had use cases where row-level s
[changing subject, as we seem to have done]
Tom Lane wrote:
David Fetter writes:
On Mon, Jul 20, 2009 at 01:00:12PM -0400, Tom Lane wrote:
I might think about it when/if we move to git.
As far as you're concerned, what's blocking that?
Lack of committer familiarit
Joshua Brindle wrote:
Peter Eisentraut wrote:
When it comes to larger features, this development group has a great
deal of
experience in implementing existing specifications, even relatively
terrible
ones like SQL or ODBC or Oracle compatibility. But the expected
behavior has
to be writte
On Mon, Jul 20, 2009 at 12:29 PM, Greg Stark wrote:
> On Mon, Jul 20, 2009 at 7:40 PM, Alan Li wrote:
> > Attached is an updated patch that removes the O(n^2) behavior and the
> > awkwardness of optimizing the seqscan path as the plan was about to be
> > created. Now, the optimization is conside
David Fetter writes:
> On Mon, Jul 20, 2009 at 01:00:12PM -0400, Tom Lane wrote:
>> I might think about it when/if we move to git.
> As far as you're concerned, what's blocking that?
Lack of committer familiarity with git, lack of a bulletproof migration
process, uncertainty about preferred mult
Peter Eisentraut wrote:
On Monday 20 July 2009 21:05:38 Joshua Brindle wrote:
How many people are you looking for? Is there a number or are you waiting
for a good feeling?
In my mind, the number of interested people is relatively uninteresting, as
long as it is greater than, say, three.
Wha
Ron Mayer wrote:
Joshua Brindle wrote:
How many people are you looking for? Is there a number or are you
waiting for a good feeling?
Joshua - if you're still associated with Tresys - could someone
who could speak for that company say what they think about this
project? The seem quite in-t
I wrote:
> I'm still interested in the idea of doing a manual unroll instead of
> relying on a compiler-specific feature. However, some quick testing
> didn't find an unrolling that helps much.
Hmm, actually this seems to work ok:
idx++;
size >>= 1;
if (size != 0)
Joshua Brindle wrote:
> How many people are you looking for? Is there a number or are you
> waiting for a good feeling?
Is it individuals or organizations people are looking for?
I see KaiGai wrote "In addition, I (and NEC) can provide our
capability to the PostgreSQL community to keep these secu
On Mon, Jul 20, 2009 at 7:40 PM, Alan Li wrote:
> Attached is an updated patch that removes the O(n^2) behavior and the
> awkwardness of optimizing the seqscan path as the plan was about to be
> created. Now, the optimization is considered when appendrel is generating
> the paths.
>
> I also chang
Stefan Kaltenbrunner writes:
> Tom Lane wrote:
>> and it turns out that Intel hasn't seen fit to put a lot of effort into
>> the BSR instruction. It's constant time, all right, but on most of
>> their CPUs that constant time is like 8 or 16 times slower than an ADD;
>> cf http://www.intel.com/Ass
Peter Eisentraut wrote:
On Monday 20 July 2009 21:05:38 Joshua Brindle wrote:
How many people are you looking for? Is there a number or are you waiting
for a good feeling?
In my mind, the number of interested people is relatively uninteresting, as
long as it is greater than, say, three.
What
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > Something is certainly wrong. Did we change sequence table format from
> > > 8.3 to 8.4?
> >
> > 8.3 does not have start_value.
>
> Looking at an invalidly-migrated sequence's columns:
>
> regression=> \d ser
On Mon, Jul 20, 2009 at 01:00:12PM -0400, Tom Lane wrote:
> David Fetter writes:
> >> Please, no. Constraints are not a datatype. Do not copy the brain-dead
> >> decision that put ri_triggers there.
>
> > Does that mean ri_triggers should come out of there?
>
> Not as long as we're on CVS ---
On Monday 20 July 2009 21:05:38 Joshua Brindle wrote:
> How many people are you looking for? Is there a number or are you waiting
> for a good feeling?
In my mind, the number of interested people is relatively uninteresting, as
long as it is greater than, say, three.
What is lacking here is a wr
On Sat, Jul 18, 2009 at 12:04 PM, Greg Stark wrote:
> On Sat, Jul 18, 2009 at 6:35 PM, Alan Li wrote:
> > Yeah, are you running into the same issue as well? I tried to figure out
> a
> > way around the O(n^2) behavior, but there were no existing direct
> > relationship between the child subpath
Peter Eisentraut wrote:
> On Wednesday 08 July 2009 02:09:20 Alvaro Herrera wrote:
> > It seems our makefiles fail to install fmgroids.h by "make install" in a
> > VPATH build.
>
> > I think the solution is to treat fmgroids.h just like pg_config_os.h,
> > i.e. add a line like this:
> >
> > $(
Joshua Brindle escribió:
> The unfortunate part is that many of the people that would use it are
> unable to publicly say so.
So they will be similarly unable to help with it. Such a black hole is
not of much use, is it? Or are they getting a contract with some PG
support company to which they
Tom Lane wrote:
Martijn van Oosterhout writes:
I'm asking because from my position it looks like KaiGai is being
simultaneously told "you patch is too big, make it smaller" and "your
patch is not complete (with respect to some metric), make it bigger"
and we need to define a middle ground if we
Tom Lane wrote:
Jeremy Kerr writes:
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 Fri, Jul 17, 2009 at 9:58 AM, Kevin
Grittner wrote:
> Peter Eisentraut wrote:
>
>> A facility to show it in the logs (via log_line_prefix probably)
>> would also be useful.
>
> Agreed.
>
ah! that seems a lot more useful. at least, i currently use logs to
identify malformed or bad-performant qu
Martijn van Oosterhout writes:
> I'm asking because from my position it looks like KaiGai is being
> simultaneously told "you patch is too big, make it smaller" and "your
> patch is not complete (with respect to some metric), make it bigger"
> and we need to define a middle ground if we want to av
David Fetter writes:
>> Please, no. Constraints are not a datatype. Do not copy the brain-dead
>> decision that put ri_triggers there.
> Does that mean ri_triggers should come out of there?
Not as long as we're on CVS --- it isn't worth the loss of history.
I might think about it when/if we mo
Jeremy Kerr writes:
> 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.
I
On Wed, 2009-07-15 at 17:27 +0100, Simon Riggs wrote:
> On Tue, 2009-07-14 at 21:12 -0400, Robert Haas wrote:
> >
> It's going to be very confusing if people submit their own versions of
> it. So now we have mine, Heikki's and Robert's. I'd like this to stop
> please, have a little faith and a li
Stefan Kaltenbrunner wrote:
>> My plan here would be to have
>> the dump on one machine, and run pg_restore there, and push it to a
>> database on another machine through the LAN on a 1Gb connection.
>> (This seems most likely to be what we'd be doing in real life.)
> you need to be careful he
2009/7/20 David Fetter :
> On Mon, Jul 20, 2009 at 10:21:53AM -0400, Tom Lane wrote:
>> Dean Rasheed writes:
>> >> * Please move the code that says that it should be in a new file to a
>> >> new file.
>>
>> > Ah yes, I forgot about that. Will do.
>>
>> > utils/adt/constraints.c ?
>>
>> Please, no
Robert Haas wrote:
> it might be worth testing with default settings too.
OK. I'll do that too, if time allows.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan wrote:
> To performance test this properly you might need to devise a test
> that will use a sufficiently different order of queueing items to
> show the difference.
>
> One thing I am particularly interested in is to see if queuing FK
> items for a table as soon as they become a
On Mon, Jul 20, 2009 at 6:04 PM, Kevin
Grittner wrote:
>
>> What about setting "PGLZ_strategy_always" as the default strategy
>> (insane cpu cost ?) ?
>> Or something in-between ?
>
> That goes beyond what I was trying to do with my recent patch. What
> you propose may be useful, but there would n
Laurent Laborde wrote:
> There is two compression strategy :
> static const PGLZ_Strategy strategy_default_data = {
> static const PGLZ_Strategy strategy_always_data = {
> 1) "strategy_always_data" seems to never be used.
A quick grep sure makes it look that way. I will look closer later
Martijn van Oosterhout wrote:
On Mon, Jul 20, 2009 at 10:52:44AM -0400, Joshua Brindle wrote:
Specifically, creating SELinux permissions for CREATE LANGUAGE seems
particularly useless since that's not a data protection issue. The same
with aggregates, operator classes, etc. ISTM the goal of SELi
On Mon, Jul 20, 2009 at 10:52:44AM -0400, Joshua Brindle wrote:
>>> Specifically, creating SELinux permissions for CREATE LANGUAGE seems
>>> particularly useless since that's not a data protection issue. The same
>>> with aggregates, operator classes, etc. ISTM the goal of SELinux is not
>>> primar
Hi again !
I also take a look at another possibility to improve compression.
There is two compression strategy :
static const PGLZ_Strategy strategy_default_data = {
256,/* Data chunks less than 256 bytes are not
* compressed */
614
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 ac
On Mon, Jul 20, 2009 at 10:21:53AM -0400, Tom Lane wrote:
> Dean Rasheed writes:
> >> * Please move the code that says that it should be in a new file to a
> >> �new file.
>
> > Ah yes, I forgot about that. Will do.
>
> > utils/adt/constraints.c ?
>
> Please, no. Constraints are not a datatype
Dean Rasheed writes:
>> * Please move the code that says that it should be in a new file to a
>> new file.
> Ah yes, I forgot about that. Will do.
> utils/adt/constraints.c ?
Please, no. Constraints are not a datatype. Do not copy the brain-dead
decision that put ri_triggers there.
On Friday 17 July 2009 03:51:31 Alvaro Herrera wrote:
> Nowadays the doc building process has been sped up inmensely by Peter's
> recent changes. And my machine has sped up too, as well.
Also, for the "let's switch to XML" crowd:
$ make html
make html 62.50s user 0.37s system 98% cpu 1:03.72 to
On Monday 20 July 2009 02:32:01 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
2009/7/20 Alvaro Herrera :
> 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
Hi Tom,
> 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?
OK, after attempting a macro version of this, we end up with:
#defi
On Fri, Jul 17, 2009 at 11:10 PM, Kevin
Grittner wrote:
> Laurent Laborde wrote:
>
>> What about SET STORAGE MAIN then ? To prevent out-of-line storage ?
>
> Well, that doesn't try as hard as you might think to keep from storing
> data out-of-line. It uses the same threshold as the default EXTEND
On Fri, Jul 17, 2009 at 3:38 AM, Mark Kirkwood wrote:
>
> With respect to the sum of wait times being not very granular, yes - quite
> true. I was thinking it is useful to be able to answer the question 'where
> is my wait time being spent' - but it hides cases like the one you mention.
> What woul
69 matches
Mail list logo
