On Wed, Apr 26, 2006 at 08:13:21PM -0400, Tom Lane wrote:
Actually, if xlc is behaving as Taral says then I'm pretty convinced
it's *broken*; it is assuming far more than is allowed even by the ANSI
aliasing rules. As I read the spec, ANSI aliasing says that a given
value must always be
4. Find the option for disabling strict alias and get configure to
add
that.
You'll still lose performance, but the option is -qalias=noansi.
My old xlc does not show that option, it is unfortunately version
specific.
The currently compatible option to turn it off would be -qnoansialias
Taral wrote:
4. Find the option for disabling strict alias and get configure to add
that.
You'll still lose performance, but the option is -qalias=noansi.
Next time we have this discussion I wish someone would actually document
the performance differences. IIRC most of what I
Some AMD64 dual core processor series has problem with atomic operation
lock cmpxchg. It does not work correctly in some case. (I don't know
if it is bug or feature.) This problem occurred in the solaris on the
AMD64 platform. Postgres implement own lock mechanism with similar code
lock xchg. I
On Thu, Apr 27, 2006 at 07:34:19PM +0930, Andrew Dunstan wrote:
Next time we have this discussion I wish someone would actually document
the performance differences. IIRC most of what I have seen makes it at
best marginal.
I can imagine there are cases where the performance difference is
I've sent 3 previous messages to the list, and none of them have
arrived, or been bounced.
Dave
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
Hi.
I have been thinking about this for a while and now that Google Summer of Code
is coming I thought I would share this idea.
The GCC people have traded their bison/flex parser with a hand written
recursive-descent parser for a nice speed up.
So it would be interesting to see if PostgreSQL
On Tue, Apr 25, 2006 at 10:30:26PM +0200, Jesper Pedersen wrote:
Hi.
I have been thinking about this for a while and now that Google Summer of Code
is coming I thought I would share this idea.
The GCC people have traded their bison/flex parser with a hand written
recursive-descent parser
Jesper Pedersen wrote:
I have been thinking about this for a while and now that Google Summer of Code
is coming I thought I would share this idea.
The GCC people have traded their bison/flex parser with a hand written
recursive-descent parser for a nice speed up.
So it would be
On 4/27/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
We talked about it when GCC announced their switch. The conclusion was
that our grammar is still too much a moving target, so it would be too
difficult to mantain such a grammar.
For the sake of saying again, I already have a
Martijn van Oosterhout kleptog@svana.org writes:
That's right, except I read object, not primative type. The
question revolves a bit around what an object is. This discussion on
the GCC lists [1] suggests that the syntax a-b is merely syntactic
sugar for (*a).b and thus the object being
On Thu, Apr 27, 2006 at 12:52:42PM +0200, Martijn van Oosterhout wrote:
Next time we have this discussion I wish someone would actually document
the performance differences. IIRC most of what I have seen makes it at
best marginal.
I can imagine there are cases where the performance
[EMAIL PROTECTED] writes:
Even if it was only 1% - 2%. Isn't it worth it? :-)
No. According to the ancient saying, I can make this program
arbitrarily fast ... if it doesn't have to give the right answer.
Percentage-point improvements are not worth the risk of introducing
hard-to-find,
On Thu, Apr 27, 2006 at 10:49:02AM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Even if it was only 1% - 2%. Isn't it worth it? :-)
No. According to the ancient saying, I can make this program
arbitrarily fast ... if it doesn't have to give the right answer.
Percentage-point
* Jonah H. Harris ([EMAIL PROTECTED]) wrote:
Unfortunately, this discussion usually ends up with, why would we
want to change what we have now when it already works?
The answer to that can certainly be performance provided other factors
(such as maintainability) don't change much. If you could
I ran afoul of these rules the other day when compiling pgsql 8.1 on
AIX. The configure scripts are set up to look for xlc instead of
cc, and that command invokes cc with -qalias=ansi, the ANSI-strict
pointer aliasing mode.
Can you please explain what exactly was not working ?
xlc has in the
On Thu, Apr 27, 2006 at 11:08:59AM -0400, [EMAIL PROTECTED] wrote:
... If
PostgreSQL isn't alias safe - it means that there is casting
happening, that is not generally accepted as valid, minimizing the
optimization potential of the code, and certainly not guaranteed to be
correct. Every cast
Jonah H. Harris [EMAIL PROTECTED] writes:
Unfortunately, this discussion usually ends up with, why would we
want to change what we have now when it already works?
... and is far more maintainable than an RD parser, and is not a
performance bottleneck. I've never seen yyparse occupy as much as
On 4/27/06, Stephen Frost [EMAIL PROTECTED] wrote:
The answer to that can certainly be performance provided other factors
(such as maintainability) don't change much. If you could show that
then I think such a switch would be very seriously considered.
IMHO, switching parser-types (and parser
On 4/27/06, Tom Lane [EMAIL PROTECTED] wrote:
... and is far more maintainable than an RD parser, and is not a
performance bottleneck. I've never seen yyparse occupy as much as 2%
of a backend profile ...
Not more maintainable by any stretch of the imagination. For example,
try and remove
I took the liberty of revising your README.txt as a native speaker :) I
cleaned up the grammar a lot, etc.
Thank you very much. I added your README to patch.
New version of GIN is available:
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README.txt
Changes from Try 2:
* add
Martijn van Oosterhout kleptog@svana.org writes:
You're right, PostgreSQL uses a form of subclassing, so that a (for
example) struct ArrayRefExprState is occasionally referred to using a
(struct ExprState*) or even a (struct Node*). In C, the logical way to
get that to work it by casting, do
Teodor Sigaev wrote:
* GIN stores several ItemPointer to heap tuple, so VACUUM FULL produces
this warning message:
WARNING: index idx contains 88395 row versions, but table contains
51812 row versions
HINT: Rebuild the index with REINDEX.
We
Greg Stark [EMAIL PROTECTED] writes:
Martijn van Oosterhout kleptog@svana.org writes:
You're right, PostgreSQL uses a form of subclassing, so that a (for
example) struct ArrayRefExprState is occasionally referred to using a
(struct ExprState*) or even a (struct Node*). In C, the logical way to
Alvaro Herrera [EMAIL PROTECTED] writes:
Teodor Sigaev wrote:
We appreciate any comments, help and suggestions. For third item we haven't
idea how fix it except to exclude GIN index from check.
How about adding a column to pg_am indicating these indexes must always
keep same tuple count as
On 4/27/06, Zeugswetter Andreas DCP SD [EMAIL PROTECTED] wrote:
Can you please explain what exactly was not working ?
xlc has in the past shown warnings that were actually problematic code
that gcc did not show (and the cc variant of xlc also does not show).
This has nothing to do with
On 4/27/06, Tom Lane [EMAIL PROTECTED] wrote:
Greg Stark [EMAIL PROTECTED] writes:
There are other ways of achieving the same thing. Structs containing a union
for the subclass fields for example.
Doesn't achieve the same thing, unless you mandate that every part of
the system use the
How about adding a column to pg_am indicating these indexes must always
keep same tuple count as heap. This would be true for all current AMs,
false for GIN.
Yes, it's simplest solution, but it doesn't check of index consistency.
Possible, we can count number of itempointers to heap tuple
On 4/27/06, Taral [EMAIL PROTECTED] wrote:
If we do subclassing like this:
struct Node { ... };
struct Value { struct Node; ... };
etc.
do we still run into the alias problem?
Nope, it appears to get rid of the alias problem completely. But it
requires anonymous structure support (C99?) to
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Change log message about vacuuming database name from LOG to DEBUG1.
Prevents duplicate meaningless log messsages.
Could we have some discussion about this sort of thing, rather than
unilateral actions?
Those messages were at
On Thu, Apr 27, 2006 at 12:21:55PM -0500, Taral wrote:
If we do subclassing like this:
struct Node { ... };
struct Value { struct Node; ... };
etc.
do we still run into the alias problem?
Nope, it appears to get rid of the alias problem completely. But it
requires anonymous
I think there are two things people typically want to know from the logs:
1) Is autovacuum running
2) Did autovacuum take action (issue a VACUUM or ANALYZE)
I don't think we need mention the name of each and every database we
touch, we can, but it should be at a lower level like DEBUG1 or
Matthew T. O'Connor wrote:
I think there are two things people typically want to know from the logs:
1) Is autovacuum running
2) Did autovacuum take action (issue a VACUUM or ANALYZE)
I don't think we need mention the name of each and every database we
touch, we can, but it should be at a
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
I think there are two things people typically want to know from the
logs: 1) Is autovacuum running 2) Did autovacuum take action (issue
a VACUUM or ANALYZE)
I don't think we need mention the name of each and every database we
touch, we can,
The ideal thing would be for GIN to return a count of the number of
distinct heap tuples referenced by the entries in the index, but I
suppose that would be impractical for VACUUM to compute.
Of course, in this case we should collect heap pointers in memory..
--
Teodor Sigaev
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
I would argue that what people typically want is
(0) nothing
(1) per-database log messages
or
(2) per-table log
On 4/27/06, Tom Lane [EMAIL PROTECTED] wrote:
I suggest that maybe the cleanest solution is to not use log level at
all for this, but to invent a separate autovacuum_verbosity setting
that controls how many messages autovac tries to log, using the above
scale. Anything it does try to log can
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
I would argue that what people typically want is
(0) nothing
(1) per-database log messages
or
(2)
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
There are other ways of achieving the same thing. Structs containing a union
for the subclass fields for example.
Doesn't achieve the same thing, unless you mandate that every part of
the system use the identical
On 27 Apr 2006 15:25:45 -0400, Greg Stark [EMAIL PROTECTED] wrote:
It would be pretty cool to have a type-safe codebase. It just seems like too
an awful lot of work for a mostly aesthetic improvement.
Does anyone have some benchmarks I can run? I can run tests to see if
this aliasing makes a
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Doesn't achieve the same thing, unless you mandate that every part of
the system use the identical massively-overloaded union struct to refer
to every node.
Are you saying it's important to preserve the ability for
[EMAIL PROTECTED] (Tom Lane) writes:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
I would argue that what people typically want is
(0) nothing
(1) per-database log
Uh, while you are at it, the background writer and checkpoint operations
need similar treatment. :-)
---
Larry Rosenman wrote:
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete
Bruce Momjian wrote:
Uh, while you are at it, the background writer and checkpoint
operations need similar treatment. :-)
Sure.
I'm willing to look at and work it out, if no one else is currently
working on it.
LER
Chris Browne [EMAIL PROTECTED] writes:
At level 2, it seems to me that it would be quite useful to have
some way of getting at the verbose output of VACUUM.
I think you can do that now, if you set min_log_level to INFO. However,
it might be cleaner if we allowed a level 3 that made all of
Tom Lane wrote:
Chris Browne [EMAIL PROTECTED] writes:
At level 2, it seems to me that it would be quite useful to have
some way of getting at the verbose output of VACUUM.
I think you can do that now, if you set min_log_level to INFO.
However, it might be cleaner if we allowed a level 3
Larry Rosenman wrote:
Tom Lane wrote:
Chris Browne [EMAIL PROTECTED] writes:
At level 2, it seems to me that it would be quite useful to have
some way of getting at the verbose output of VACUUM.
I think you can do that now, if you set min_log_level to INFO.
However, it might be
Alvaro Herrera [EMAIL PROTECTED] writes:
Also it'd be nice to have it a (4th?) level which would show the results
of the equations being applied.
That I think would fall more naturally into the category of debug
support --- I'm happy if we just emit that at DEBUG1 and let people
select it with
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Also it'd be nice to have it a (4th?) level which would show the
results of the equations being applied.
That I think would fall more naturally into the category of debug
support --- I'm happy if we just emit that at DEBUG1 and let
On Thu, Apr 27, 2006 at 02:42:35PM -0500, Taral wrote:
On 27 Apr 2006 15:25:45 -0400, Greg Stark [EMAIL PROTECTED] wrote:
It would be pretty cool to have a type-safe codebase. It just seems like
too an awful lot of work for a mostly aesthetic improvement.
Does anyone have some benchmarks I
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
autovacuum_verbosity
Should we call it autovacuum_messages?
In current usage...
_verbosity
Simon Riggs wrote:
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
autovacuum_verbosity
Should we call it autovacuum_messages?
In current
I suspect a patch to convert PostgreSQL to C++ wouldn't be
welcomed. Haha...
Checking my calendar, I think you are about 26 days too late to make
that suggestion...
-rocco
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
For the sake of saying again, I already have a recursive-descent
parser for PostgreSQL written in a PCCTS grammar. It's something I
started writing years ago, but I'd be willing to consider open
sourcing it if the PostgreSQL community will really entertain the
thought of switching.
On 4/27/06, Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Is it faster? How much faster?
I'm not sure, I haven't done direct timings on it vs. the bison
version. When I wrote it, I wasn't really concerned with the time it
took to parse.
--
Jonah H. Harris, Database Internals Architect
Those messages were at LOG level because otherwise it's difficult to be
sure from the log that autovac is running at all.
OK, so what do we want to do? Clearly outputing something everytime
pg_autovacuum touches a database isn't ideal. By default, the server
logs should show significant
I suggest that maybe the cleanest solution is to not use log level at
all for this, but to invent a separate autovacuum_verbosity setting
that controls how many messages autovac tries to log, using the above
scale. Anything it does try to log can just come out at LOG message
setting.
+1
I was wondering (for planning purposes) if anyone knew the status of
constraint exclusions moving up to query runtime and working for
joins. Is this something that's coming down the pipe in the
foreseeable future, or just on a back-burner to-do list, or probably
never happening, or... ?
I have a
Jonah H. Harris wrote:
On 4/27/06, Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Is it faster? How much faster?
I'm not sure, I haven't done direct timings on it vs. the bison
version. When I wrote it, I wasn't really concerned with the time it
took to parse.
Is the source easier to
On 4/27/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Is the source easier to maintain?
Yes, aside from extra lookahead, that was my main motivation.
--
Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
732.331.1324
---(end of
Brandon Black [EMAIL PROTECTED] writes:
I was wondering (for planning purposes) if anyone knew the status of
constraint exclusions moving up to query runtime and working for
joins.
The latter, done; the former, not on the radar screen IMHO.
regards, tom lane
61 matches
Mail list logo
