On Thu, 16 Jun 2005, Matthew T. O'Connor wrote:
Gavin Sherry wrote:
I guess my main concern is that we'll have a solution to the problem of
dead tuples which is only half way there. It is only an incremental
improvement upon the contrib module and solves only one real problem:
users do not
On Thu, 2005-06-16 at 01:10 -0400, Greg Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If you really do need that many, you can go to the trouble of grouping
them in two levels of nesting, so you have a root table, multiple month
tables and then each month table with multiple day
On Thu, 2005-06-16 at 12:59 +0800, Christopher Kings-Lynne wrote:
Well, it's not so much that I care about queries with 1000+ relations,
as that this is a good way to stress-test the code and find out where
the performance issues are. There are many thousand lines of code that
can never
Hello
I did some work on implementation of user's exception.
Generally:
o add pseudotype EXCEPTION
DECLARE excpt EXCEPTION [= 'SQLSTATE']
o change RAISE stmt
RAISE error_level [excpt_var|sys_excpt_name] errmsg, ...
o change EXCEPTION
EXCEPTION WHEN
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback. Vacuum
at peak times can cause very intense IO bursts -- even with the
enhancements
If we do integrated AV, it should only be turned on by
default at a relatively low level. And wasn't there an issue
on Windows with AV not working?
AFAIK, it works.
But the fact that you need to provide it with a userid/password combo
makes it a lot harder to install as a service. And it's
On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback. Vacuum
at peak
Gavin Sherry wrote:
On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jrgen Schnig wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback.
On Thu, 2005-06-16 at 00:55 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Looks bad... but how does it look for 1000 inherited relations? My
feeling is that we should not be optimizing the case above 1000
relations. That many partitions is very unwieldy.
Well, it's not so
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: 16 June 2005 10:15
To: Josh Berkus; Gavin Sherry
Cc: Bruce Momjian; pgsql-hackers@postgresql.org; Dave Page
Subject: RE: [HACKERS] Autovacuum in the backend
If we do integrated AV, it should only be
Gavin Sherry said:
On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jrgen Schnig wrote:
2) By no fault of its own, autovacuum's level of granularity is the
table level. For people dealing with non-trivial amounts of data
(and we're not talking gigabytes or terabytes here), this is a
serious
Simon Riggs [EMAIL PROTECTED] writes:
Your suggested fix to the 2000+ inherited relation problem seemed like
it would apply to an area that most people would never use, yet would
have an effect on anybody using LockAcquire.
Just FYI, the proposed fix is already in, and I think it's a net win
Andrew Dunstan wrote:
Gavin Sherry said:
I think this gets away from my point a little. People with 2 TB tables
can take care of themselves, as can people who've taken the time to
partition their tables to speed up vacuum. I'm more concerned about the
majority of people who fall in the
Gavin Sherry wrote:
On Thu, 16 Jun 2005, Matthew T. O'Connor wrote:
Would you mind expounding on why you think autovacuum isn't suitable for
the general public? I know it's not a silver bullet, but I think in
general, it will be helpful for most people.
As I said, this is largely
Hans-Jrgen Schnig wrote:
I completly agree with Gavin - integrating this kind of thing into the
backend writer or integrate it with FSM would be the ideal solution.
Yes AV should look at FSM data, and it will eventually. I'm not sure
how you would integrate AV with the backend writer, but
On Wed, Jun 15, 2005 at 09:07:30PM -0700, Josh Berkus wrote:
Josh,
Just my own two cents. First I am not knocking the work that has been on
autovacuum. I am sure that it was a leap on its own to get it to work.
However I will say that I just don't see the reason for it.
I've personally
Matthew T. O'Connor wrote:
Right, I think if VACUUM is improved than the semantics of AV in the
backend might change, but I think there will always be a need for some
maintenance, and a daemon that monitors the maintenance needs of your
database and fires off appropriate maintenance
On Thu, Jun 16, 2005 at 01:32:16AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
A question for interested parties. I'm thinking in handling the
user/password issue by reading the flat files (the copies of pg_shadow,
pg_database, etc).
Er, what user/password issue?
On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback. Vacuum
at peak
[switched to -hackers]
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
It probably won't be any worse than when '' was rejected for an integer
0.
That analogy is *SO* far off the mark that I have to object.
Fooling with quoting rules will not simply cause clean failures,
Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious
Alvaro Herrera [EMAIL PROTECTED] writes:
Now, I'm hearing people don't like using libpq.
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. About all you can buy there is
Andrew Dunstan [EMAIL PROTECTED] writes:
All true. Conversely, there does need to be a path for us to get to
standard behaviour.
Yes --- but the important word there is path. I think we have to do
this in stages over a number of releases, to give people time to
migrate.
Assuming that the end
-Original Message-
From: Andreas Pflug [mailto:[EMAIL PROTECTED]
Sent: 16 June 2005 15:14
To: Dave Page
Cc: Matthew T. O'Connor; Andrew Dunstan;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; pgman@candle.pha.pa.us;
pgsql-hackers@postgresql.org
Subject: Re:
Pavel,
o User can specify SQLSTATE only from class 'U1'
o Default values for SQLSTATE usr excpt are from class 'U0'
o Every exception's variable has unique SQLSTATE
o User's exception or system's exception can be raised only with
level EXCEPTION
Any comments, notes?
Looks great to me,
Alvaro,
coffee-with-cream vacuums.
I tried this and now my Hoover makes this horrible noise and smokes. ;-)
All:
Seriously, all: when I said that users were asking for Autovac in the
backend (AVitB), I wasn't talking just the newbies on #postgresql. I'm also
talking companies like
People,
AVitB has been on the TODO list for 2 versions. There's been 2 years to
question its position there. Now people are bringing up objections when
there's no time for discussion left? This stinks.
Hmmm ... to be specific, I'm referring to the objections to the *idea* of
AVitB, not the
Dave,
In previous discussions on -hackers when ppl raised the idea of
something like pgAgent being built into the backend, istm that the
majority of people were against the idea.
Well, you're up against the minimalist approach to core PostgreSQL there. It
would pretty much *have* to be an
Hello
Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
has statement GOTO. I don't need GOTO statement, but 'continue' can be
very usefull for me. I have to do some ugly trick now. With little change,
we can enhance stmt EXIT for behavior continue.
After some work I can
Josh Berkus josh@agliodbs.com writes:
Seriously, all: when I said that users were asking for Autovac in the
backend (AVitB), I wasn't talking just the newbies on #postgresql. I'm also
talking companies like Hyperic, and whole groups like the postgresql.org.br.
This is a feature that
Pavel,
Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
has statement GOTO. I don't need GOTO statement, but 'continue' can be
very usefull for me. I have to do some ugly trick now. With little change,
we can enhance stmt EXIT for behavior continue.
Can you explain a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Now, I'm hearing people don't like using libpq.
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process.
On Thu, Jun 16, 2005 at 09:40:16 -0700,
Josh Berkus josh@agliodbs.com wrote:
Pavel,
Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
has statement GOTO. I don't need GOTO statement, but 'continue' can be
very usefull for me. I have to do some ugly trick now. With
Matthew T. O'Connor matthew@zeut.net writes:
I don't think you can use a dump to determine who should be connected to
next since you don't really know what happened since the last time you
exited. What was a priority 5 or 10 minutes ago might not be a priority
now.
Well, the information
Pavel Stehule [EMAIL PROTECTED] writes:
BEGIN
CONTINUE WHEN i = 10;
RAISE NOTICE '---1---';
END;
I find that really ugly and confusing. If we add a CONTINUE it's only
sensible to allow it inside a loop --- otherwise it's just a nonstandard
spelling of EXIT.
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
I don't think you can use a dump to determine who should be connected to
next since you don't really know what happened since the last time you
exited. What was a priority 5 or 10 minutes ago might not be a priority
now.
Pavel Stehule wrote:
What do you think about it? It's broke PL/SQL compatibility, I know, but
via last discussion I have opinion so Oracle compatibility isn't main
objective PL/pgSQL. There is some less/bigger diferencess: SQLSTATE,
EXCEPTION from my last proposal, atd.
Well, yes,
On N, 2005-06-16 at 11:42 -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
...
Some people say keep it simple and have one process per cluster. I
think they don't realize it's actually more complex, not the other way
around.
Agreed. If you aren't connected to a specific
As a near-daily PL/pgSQL developer, I similarly agree.
-Jonah
Andrew Dunstan wrote:
Pavel Stehule wrote:
What do you think about it? It's broke PL/SQL compatibility, I know,
but via last discussion I have opinion so Oracle compatibility isn't
main objective PL/pgSQL. There is some
On Thu, 16 Jun 2005, Josh Berkus wrote:
Pavel,
o User can specify SQLSTATE only from class 'U1'
o Default values for SQLSTATE usr excpt are from class 'U0'
o Every exception's variable has unique SQLSTATE
o User's exception or system's exception can be raised only with
level
On Thu, 16 Jun 2005, Josh Berkus wrote:
Pavel,
Statement CONTINUE isn't in PL/SQL too, I know it, but Oracle PL/SQL
has statement GOTO. I don't need GOTO statement, but 'continue' can be
very usefull for me. I have to do some ugly trick now. With little change,
we can enhance stmt
On Thu, 16 Jun 2005, Tom Lane wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
BEGIN
CONTINUE WHEN i = 10;
RAISE NOTICE '---1---';
END;
I find that really ugly and confusing. If we add a CONTINUE it's only
sensible to allow it inside a loop --- otherwise it's just a
Well, yes, but I don't think we should break compatibility
arbitrarilly. I guess it could be argued that this is a missing feature
in PL/SQL and its Ada parent - implementing GOTO just to handle this
case seems unnecessary.
Yes. I din't use goto 5 years :-). Continue stmt is more
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: 16 June 2005 17:29
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Autovacuum in the backend
Dave,
In previous discussions on -hackers when ppl raised the idea of
something like
Josh Berkus wrote:
Dave,
In previous discussions on -hackers when ppl raised the idea of
something like pgAgent being built into the backend, istm that the
majority of people were against the idea.
Well, you're up against the minimalist approach to core PostgreSQL there. It
would pretty
Hackers,
SpikeSource is now doing automated testing of the PostgreSQL code in their
stack testing platform. This includes:
* SpikeSource has incorporated the testing of PostgreSQL into
the company's 22,000 nightly automated test runs. SpikeSource includes
the code coverage of PostgreSQL, as
Andreas Pflug wrote:
We're having a growing zoo of daemons that can be regarded as tightly
integrated server add-on processes (slony, autovac, pgAgent), and it
would be really nice (say: win32 users are used to it, thus requiring
it) to have a single point of control.
Maybe a super
On Thu, 16 Jun 2005, Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes
Andrew Dunstan wrote:
Andreas Pflug wrote:
We're having a growing zoo of daemons that can be regarded as tightly
integrated server add-on processes (slony, autovac, pgAgent), and it
would be really nice (say: win32 users are used to it, thus requiring
it) to have a single point of
Title: MemoryContextAlloc: invalid request size
Our customer is reporting a database problem after they ran into a
disk quota/filesystem full situation.
This is Postgres 7.2.x on Solaris.
The database server starts without any obvious errors, but the app. Server
cannot establish
Hey, Folks,
I need to find someone who's really interesed in working with DTrace. Sun
has offered to help put DTrace probes into PostgreSQL for advanced
profiling, but need to know where to probe. Anyone?
I'm afraid that I won't get around to this quickly enough.
--
--Josh
Josh Berkus
Josh Berkus wrote:
Alvaro,
coffee-with-cream vacuums.
I tried this and now my Hoover makes this horrible noise and smokes. ;-)
Probably related to the quality of American coffee ;).
All:
Seriously, all: when I said that users were asking for Autovac in the
backend (AVitB), I wasn't
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
All true. Conversely, there does need to be a path for us to get to
standard behaviour.
Yes --- but the important word there is path. I think we have to do
this in stages over a number of releases, to give people time to
migrate.
Bruce Momjian said:
OK, the current patch warns about two things, \' with one message, and
any backslash in a non-E string with a different message. The \'
message can easily be avoided in clients even in 8.0 by using '', but
for E'', there is no way to prepare an application before
Andrew Dunstan wrote:
Bruce Momjian said:
OK, the current patch warns about two things, \' with one message, and
any backslash in a non-E string with a different message. The \'
message can easily be avoided in clients even in 8.0 by using '', but
for E'', there is no way to prepare an
Tom Lane [EMAIL PROTECTED] writes:
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. About all you can buy there is having the
postmaster spawn the autovacuum process,
Gavin Sherry wrote:
In January I was in Toronto with Jan, Tom and others and some ideas about
vacuum were being discussed. The basic idea is that when we dirty pages we
need we set a bit in a bitmap to say that the page has been dirty. A
convenient place to do this is when we are writing dirty
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, the current patch warns about two things, \' with one message, and
any backslash in a non-E string with a different message.
Those are two very different things. \' is easy to get around and
there's no very good reason not to send '' instead.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, the current patch warns about two things, \' with one message, and
any backslash in a non-E string with a different message.
Those are two very different things. \' is easy to get around and
there's no very good reason not
Gavin,
For the record, I don't consider myself a PostgreSQL newbie, nor do I
manage any 2 TB databases (much less tables), but I do have an
unusual production use case: thousands ( 10,000) of tables, many of
them inherited, and many of them with hundreds of thousands (a few
with
On Jun 17, 2005, at 12:33 PM, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, the current patch warns about two things, \' with one message,
and
any backslash in a non-E string with a different message.
Those are two very different things. \' is easy to get around and
61 matches
Mail list logo
