"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
---
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)---
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
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
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
---
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
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
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
> 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
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?
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
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
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
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
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
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
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
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
>
---
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
[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
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
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
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
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
>
>
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
"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
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
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
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
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
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
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 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 (
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, 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
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
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
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
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
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
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
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
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
"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 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
> 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
* 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
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
[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 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
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 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
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 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
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
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
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
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".
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
> > 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
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
61 matches
Mail list logo