Hi,
On Tue, 2007-07-31 at 01:54 -0400, Tom Lane wrote:
> > Really? Are the compiler options, etc, public?
>
> Certainly. If you doubt it, try comparing pg_config output for the
> RHEL and CentOS packages.
As I wrote before, I used PGDG packages for both -- What I'm suspecting
is the other pack
On Mon, 30 Jul 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
OK, here is what I am thinking. If we make default_text_search_config
super-user-only, then the user can't do SET (using "zero_damaged_pages"
as a superuser-only example):
test=> set zero_damaged_pages = on;
ERROR:
On 7/31/07, Devrim GÜNDÜZ <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Mon, 2007-07-30 at 19:14 -0700, Joshua D. Drake wrote:
> > > and RHEL performed much better than CentOS.
> >
> > Not to be unkind, but I doubt that on an identical configuration.
>
> Since I don't have the permission to distribute th
Decibel! wrote:
> Moving to -hackers.
>
> On Jul 27, 2007, at 1:22 PM, Stuart wrote:
>> Does Postgresql have a function like ascii() that will
>> return the unicode codepoint value for a utf8 character?
>> (And symmetrically same for question chr() of course).
> I suspect that this is just a matte
On Jul 30, 2007, at 8:00 PM, Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
I think we might need additional "freezing-xmax" operations to
avoid
XID-wraparound in the first path of vacuum, though it hardly
occurs.
I'm not sure I follow. Can you ela
Decibel! wrote:
> On Jul 30, 2007, at 8:00 PM, Alvaro Herrera wrote:
>> ITAGAKI Takahiro wrote:
>>> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> I think we might need additional "freezing-xmax" operations to avoid
> XID-wraparound in the first path of vacuum, though it hardly occurs.
>>
Simon Riggs wrote:
> 1. Increase size of Clog-specific BLCKSZ
> 2. Perform ExtendClog() as a background activity
> (1) and (2) can be patched fairly easily for 8.3. I have a prototype
> patch for (1) on the shelf already from 6 months ago.
Hmm, I think (1) may be 8.3 material but all the rest a
On Jul 30, 2007, at 1:47 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
On Jul 27, 2007, at 1:49 AM, Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
It would be cool if we could do something like sweep a range of
pages,
initiate IO for those that are not in shared buffers, and while
that is
runni
On Mon, 30 Jul 2007, Devrim G?ND?Z wrote:
I have performed a test using OSDL test suite a few months ago on a
system that has:
* 8 x86_64 CPUs @ 3200.263...
and RHEL [4.3] performed much better than CentOS [4.3]
RHEL 4 update 3 included some reworking of the x86_64 kernel, like adding
the ker
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> 1. Increase size of Clog-specific BLCKSZ
>> 2. Perform ExtendClog() as a background activity
>> (1) and (2) can be patched fairly easily for 8.3. I have a prototype
>> patch for (1) on the shelf already from 6 months ago.
> Hmm,
Gavin,
I'm actually in the middle of assembling a general performance test lab for
the PostgreSQL hackers, using equipment donated by Sun, Hi5, and (hopefully)
Unisys and Intel. While your machine would obviously stay in Pennsylvania,
it would be cool if we could somehow arrange a unified auth
Stephen Frost <[EMAIL PROTECTED]> writes:
> Other, unrelated, options being or not being there doesn't really have
> any bearing on this though. I'm not inventing new syntax here. I'm
> just removing a restriction on what the user can do that doesn't need
> to exist.
I don't think you're "just r
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I agree. Let's remove stats_start_collector and merge the other two
> into a single setting. Anything more than that is overkill.
So what are we going to call the one surviving GUC variable?
regards, tom lane
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I agree. Let's remove stats_start_collector and merge the other two
> > into a single setting. Anything more than that is overkill.
>
> So what are we going to call the one surviving GUC variable?
"collect_stats"
--
Alvaro Herre
On Tue, 2007-07-31 at 12:33 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > I agree. Let's remove stats_start_collector and merge the other two
> > > into a single setting. Anything more than that is overkill.
> >
> > So what are we going to ca
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
Other, unrelated, options being or not being there doesn't really have
any bearing on this though. I'm not inventing new syntax here. I'm
just removing a restriction on what the user can do that doesn't need
to exist.
I don'
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Simon Riggs wrote:
>>> 1. Increase size of Clog-specific BLCKSZ
>
>>> 2. Perform ExtendClog() as a background activity
>
>>> (1) and (2) can be patched fairly easily for 8.3. I have a prototype
>>> patch for (1) on the shelf already
Simon Riggs wrote:
> On Tue, 2007-07-31 at 12:33 -0400, Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > I agree. Let's remove stats_start_collector and merge the other two
> > > > into a single setting. Anything more than that is overkill.
> > >
It's actually in Texas, and we have no intention to put a time limit
on its availability. I think the availability will be there as long as
there is use and we're in the Texas data center, which I don't see
ending any time soon.
On 7/31/07, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Gavin,
>
> I'm a
On Tue, 2007-07-31 at 13:06 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Tue, 2007-07-31 at 12:33 -0400, Alvaro Herrera wrote:
> > > Tom Lane wrote:
> > > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > > I agree. Let's remove stats_start_collector and merge the other two
> > > >
Folks,
Hey, this is looking like a serious case of "Bike Shedding". That is, a dozen
people are arguing about what color to paint the bike shed instead of getting
it built.[1]
Given that there are much more substantial issues: what performance software
to install and how to install it, how to
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Methinks it should be: stats_, so that people find it in the
>> same place as stats_query_string, which is still there.
> Hum, but the order in postgresql.conf is arbitrary, right?
I concur with Simon that it should have some rela
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> ... Oh, and if we did allow the
> quote char we should surely only allow it on input - just because other
> programs produce absurd output there is not reason we should.
Yeah. The *real* problem with the patch as proposed is that it allows a
COPY OUT
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> FWIW I just noticed we have a variable named "krb_caseins_users" which I
> think is not such a great name for it. Prolly best to change it now
> while it's still in the oven.
You're two releases too late for that one :-(
regard
Josh Berkus <[EMAIL PROTECTED]> writes:
> Hey, this is looking like a serious case of "Bike Shedding". That is, a
> dozen
> people are arguing about what color to paint the bike shed instead of getting
> it built.[1]
FWIW, it's looking like Red Hat will donate a RHEL/RHN subscription if
we wan
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > FWIW I just noticed we have a variable named "krb_caseins_users" which I
> > think is not such a great name for it. Prolly best to change it now
> > while it's still in the oven.
>
> You're two releases too late for that one :-(
Do
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> Methinks it should be: stats_, so that people find it in the
> >> same place as stats_query_string, which is still there.
>
> > Hum, but the order in postgresql.conf is arbitrary, right?
>
> I concur with Sim
On Mon, 30 Jul 2007, Bruce Momjian wrote:
Bruce Momjian wrote:
We have to decide if we want a GUC default_text_search_config, and if so
when can it be changed.
Right now there are three ways to create a tsvector (or tsquery)
::tsvector
to_tsvector(value)
to_tsvector(co
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Or we could get radical and rename both of them...
> Well, it is a bit misleading to have the query_string stuff be named
> "stats" when it's not actually collected by pgstats at all. Maybe
> rename it to "collect_query_string". Wit
Oleg Bartunov wrote:
> >> If we remove default_text_search_config, it would also make ::tsvector
> >> casting useless as well.
> >
> > OK, I just found a case that I think is going to make #3 a requirement
> > (remove default_text_search_config).
> >
> > How is a CREATE INDEX ... to_tsvector(col) g
On Tue, 31 Jul 2007, Josh Berkus wrote:
That is, a dozen people are arguing about what color to paint the bike
shed instead of getting it built.
Until there's an OS installed on it and it's on a network, the machine
essentially doesn't exist--so there was no way to work on the
building--and
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > ... Oh, and if we did allow the
> > quote char we should surely only allow it on input - just because other
> > programs produce absurd output there is not reason we should.
>
> Yeah. The *real* problem with
Alvaro Herrera wrote:
> Well, it is a bit misleading to have the query_string stuff be named
> "stats" when it's not actually collected by pgstats at all.
By now, the statistics collector is unnoticeable to most users, since
it's always on and you never have to do anything about it. The fact
th
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Or we could get radical and rename both of them...
>
>> Well, it is a bit misleading to have the query_string stuff be named
>> "stats" when it's not actually collected by pgstats at all. Ma
People,
I'd like to suggest you guys to implement a new feature.
Actually is an alias for a existent feature.
Unstead of having to type all the insert syntax, using ("column") names, you
could do the same as MySQL does.
for example:
INSERT INTO Table SET
"Field1" = 'text',
"Field2" = 'text';
So
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> Methinks it should be: stats_, so that people find it in the
> >> same place as stats_query_string, which is still there.
>
> > Hum, but the order in postgresql.conf is arbitrary, right?
>
> I concur with Sim
Rafael Azevedo wrote:
> People,
>
> I'd like to suggest you guys to implement a new feature.
> Actually is an alias for a existent feature.
>
> Unstead of having to type all the insert syntax, using ("column") names, you
> could do the same as MySQL does.
> for example:
>
> INSERT INTO Table SET
On Tue, 31 Jul 2007, Bruce Momjian wrote:
And if we have to require the configuration name in CREATE INDEX, it has
to be used in WHERE, so we might as well just remove the default
capability and always require the configuration name.
this is very rare use case for text searching
1. expression
Oleg Bartunov wrote:
> On Tue, 31 Jul 2007, Bruce Momjian wrote:
>
> >>> And if we have to require the configuration name in CREATE INDEX, it has
> >>> to be used in WHERE, so we might as well just remove the default
> >>> capability and always require the configuration name.
> >>
> >> this is ver
"Rafael Azevedo" <[EMAIL PROTECTED]> writes:
> Unstead of having to type all the insert syntax, using ("column") names, you
> could do the same as MySQL does.
> for example:
>
> INSERT INTO Table SET
> "Field1" = 'text',
> "Field2" = 'text';
>
> So it would make it easier and faster to develop app
Gregory Stark wrote:
> "Rafael Azevedo" <[EMAIL PROTECTED]> writes:
>
> > Unstead of having to type all the insert syntax, using ("column") names, you
> > could do the same as MySQL does.
> > for example:
> >
> > INSERT INTO Table SET
> > "Field1" = 'text',
> > "Field2" = 'text';
> >
> > So it wou
Tom,
> FWIW, it's looking like Red Hat will donate a RHEL/RHN subscription if
> we want one, though I don't have final approval quite yet.
Great. Any chance of a machine? Can RH exert some leverage with Dell?
We could use up to 8 servers for performance testing, so I'm asking
everyone.
--
-
Imagine that you have about 30 fields.
Ok, then your first SQL is done.
Now, you just have to add 10 more fields.
Its very easy to get lost. If we have this implementation, you could just
add
Field31 = 'text',
Field32 = 'text'
...
wherever you want.
This is just a PLUS. I just don't see any probl
Rafael,
> This is just a PLUS. I just don't see any problem by doing this.
> Even knowing that this is not Standard SQL-Syntax, I just see this as a
> benefit feature.
Our project has a policy of upholding the SQL standard whereever possible.
For that reason, we don't approve non-standard synta
Hi,
I've started reading the GIT patch to see if I can help with the review.
First thing I notice is that there are several things that seems left
over; for example the comments in pg_proc for the new functions are
incomplete.
More subtle: in _bt_findinsertloc, the test for
modifiedpage = _bt_gro
On 8/1/07, Rafael Azevedo <[EMAIL PROTECTED]> wrote:
> Imagine that you have about 30 fields.
> Ok, then your first SQL is done.
> Now, you just have to add 10 more fields.
> Its very easy to get lost. If we have this implementation, you could just
> add
>
> Field31 = 'text',
> Field32 = 'text'
I
Well. Ok.
Then I'll just do it myself.
Just thought it would be good for thousands of users.
As I said, it was just a suggestion.
I surely aint the only one who ever thought about it.
Thanks anyway.
2007/7/31, Josh Berkus <[EMAIL PROTECTED]>:
>
> Rafael,
>
> > This is just a PLUS. I just don't s
On Tue, 31 Jul 2007, Bruce Momjian wrote:
Oleg Bartunov wrote:
On Tue, 31 Jul 2007, Bruce Momjian wrote:
And if we have to require the configuration name in CREATE INDEX, it has
to be used in WHERE, so we might as well just remove the default
capability and always require the configuration na
Another thing that would be useful would be to separate the changes to
add pgstat counters and view columns, since they are relatively minor
and could be committed separately (or not at all for 8.3, even).
--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
really,
From: Alvaro Herrera
> Decibel! wrote:
> > Moving to -hackers.
> >
> > On Jul 27, 2007, at 1:22 PM, Stuart wrote:
> >> Does Postgresql have a function like ascii() that will
> >> return the unicode codepoint value for a utf8 character?
> >> (And symmetrically same for question chr() of course).
>
Oh, and the new function in bitmapset.c could use with some explanation
of what it is.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Es filósofo el que disfruta con los enigmas" (G. Coli)
---(end of broadcast)--
Tom Lane wrote:
FWIW, it's looking like Red Hat will donate a RHEL/RHN subscription if
we want one, though I don't have final approval quite yet.
One possible point favoring the use of Centos over RHEL - its a little
easier for community members to reproduce or test any findings... i.
52 matches
Mail list logo
