On 31-7-2007 5:07 Alvaro Herrera wrote:
Arjen van der Meijden wrote:
Afaik Tom hadn't finished his patch when I was testing things, so I don't
know. But we're in the process of benchmarking a new system (dual quad-core
Xeon) and we'll have a look at how it performs in the postgres 8.2dev we
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 packages
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 the benchmark
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 matter of no
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
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.
I'm not sure I follow.
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 are
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
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
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
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 call the one
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't
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 from 6 months ago.
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.
So what are we
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
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
into a single
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_something, 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
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 to
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 :-(
regards, tom
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 want one,
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 :-(
Doh, I thought
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Methinks it should be: stats_something, 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
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)
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. With the other
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) going to restore
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 the patch
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
that
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. Maybe
rename it to
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 it
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Methinks it should be: stats_something, 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
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
Field1 =
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 very rare use case for
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 applications using
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 would make it easier and faster
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
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 syntax
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 =
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 have to
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 see any
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
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/
inflex
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).
I suspect
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)---
48 matches
Mail list logo
