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 ac
> > 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 -qnoansi
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 ha
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".
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
n
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 wou
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 p
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 int
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 recursive-d
Martijn van Oosterhout 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 accessed is (
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, compil
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 impr
* 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
> 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 h
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 c
"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 m
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
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 remov
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 reg
Martijn van Oosterhout 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 you have a bet
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 a
Greg Stark <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout 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 t
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
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 war
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 u
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 du
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 (
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 w
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
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 someth
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
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
>> tou
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
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 l
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
>
>
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
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 abil
[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-datab
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 c
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
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
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
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 wi
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 a
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 benchm
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...
_ve
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?
> 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.
Unfortunately
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
En
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 events
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 ea
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 broadcast)---
"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
