Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
But we've already had a couple of cases of interesting failures going
unnoticed because of the noise level. Between duplicate reports about
busted patches and transient problems on particular build machines
(out of disk space,
On Tue, 2007-03-20 at 14:14 +1200, Mark Kirkwood wrote:
Jeff Davis wrote:
I know we can't keep stats on every combination of columns. My initial
idea would be to only keep stats about a multi-column index (and
probably optional for those, too).
Maybe you would want to keep single
Simon Riggs wrote:
On Tue, 2007-03-20 at 14:14 +1200, Mark Kirkwood wrote:
Jeff Davis wrote:
I know we can't keep stats on every combination of columns. My initial
idea would be to only keep stats about a multi-column index (and
probably optional for those, too).
Maybe you would want to keep
On Tue, Mar 20, 2007 at 02:57:13AM -0400, Tom Lane wrote:
Maybe we should think about filtering the noise. Like, say, discarding
every report from mongoose that involves an icc core dump ...
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2007-03-20%2006:30:01
Maybe a simple
I've noticed that if for example the autovacuum process dies (such as
with a kill -9 when testing my new shared mem implementation), only
autovac and bgwriter are restarted. The stats collector is terminated,
but not restarted. (Same goes for a regular backend, and not just
autovac)
Is there a
Richard Huxton wrote:
Simon Riggs wrote:
On Tue, 2007-03-20 at 14:14 +1200, Mark Kirkwood wrote:
Jeff Davis wrote:
I know we can't keep stats on every combination of columns. My initial
idea would be to only keep stats about a multi-column index (and
probably optional for those, too).
Magnus Hagander wrote:
I've noticed that if for example the autovacuum process dies (such as
with a kill -9 when testing my new shared mem implementation), only
autovac and bgwriter are restarted. The stats collector is terminated,
but not restarted. (Same goes for a regular backend, and not
Martijn van Oosterhout wrote:
On Tue, Mar 20, 2007 at 02:57:13AM -0400, Tom Lane wrote:
Maybe we should think about filtering the noise. Like, say, discarding
every report from mongoose that involves an icc core dump ...
Alvaro Herrera wrote:
Is there a better way than going to time_t and back? I am currently
using this:
db-next_worker =
time_t_to_timestamptz(timestamptz_to_time_t(current_time) +
autovacuum_naptime);
(db-next_worker is a
Florian G. Pflug wrote:
Are we really sure that this isn't a solution in search of a problem?
I think this really depends on how you define problem. Some people
might think that select * from myfunc(...) limit 1 should stop and
return a result after myfunc(...) has returned one row. Others will
Andrew Dunstan wrote:
Martijn van Oosterhout wrote:
On Tue, Mar 20, 2007 at 02:57:13AM -0400, Tom Lane wrote:
Maybe we should think about filtering the noise. Like, say, discarding
every report from mongoose that involves an icc core dump ...
Stefan Kaltenbrunner wrote:
however as a buildfarm admin I occasionally wished i had a way to
invalidate reports generated from my boxes to prevent someone wasting
time to investigate them (like errors caused by system
upgrades,configuration problems or other local issues).
It would be
Andrew Dunstan wrote:
The buildfarm works because it leverages our strength, namely automating
things. But all the tagging suggestions I've seen will involve regular,
repetitive and possibly boring work, precisely the thing we are not good
at as a group.
You may be forgetting that Martijn
Alvaro Herrera wrote:
Andrew Dunstan wrote:
The buildfarm works because it leverages our strength, namely automating
things. But all the tagging suggestions I've seen will involve regular,
repetitive and possibly boring work, precisely the thing we are not good
at as a group.
You
Alvaro Herrera wrote:
Now, the hard question is deciding what to keep track of. I don't
think MCV makes much sense, because what's the MCV of two columns?
The combination that occurs most often.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Andrew Dunstan [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
Maybe a simple compromise would be being able to setup a set of regexes
that search the output and set a flag it that string is found. If you
find the string, it gets marked with a flag, which means that when you
look at
On Tue, Mar 20, 2007 at 08:48:30AM -0400, Alvaro Herrera wrote:
Magnus Hagander wrote:
I've noticed that if for example the autovacuum process dies (such as
with a kill -9 when testing my new shared mem implementation), only
autovac and bgwriter are restarted. The stats collector is
Alvaro Herrera [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
I've noticed that if for example the autovacuum process dies (such as
with a kill -9 when testing my new shared mem implementation), only
autovac and bgwriter are restarted. The stats collector is terminated,
but not restarted.
Alvaro Herrera [EMAIL PROTECTED] writes:
It was also suggested that column pairs in FK relationship could be
automatically enabled. So you don't need to specify those manually.
Actually, I think you don't particularly need stats for that in most
cases --- if the planner simply took note that
Tom Lane wrote:
The point I think you are missing is that having something like this
will *eliminate* repetitive, boring work, namely recognizing multiple
reports of the same problem. The buildfarm has gotten big enough that
some way of dealing with that is desperately needed, else our ability
Magnus Hagander [EMAIL PROTECTED] writes:
Bah, sorry about the noise. It was the effect of
PGSTAT_RESTART_INTERVAL.
Do we want to add some logging when we don't restart it due to repeated
failures?
Not really, but maybe it would be sensible to reset last_pgstat_start_time
when doing a
Ühel kenal päeval, T, 2007-03-20 kell 09:35, kirjutas Andrew Dunstan:
Florian G. Pflug wrote:
Are we really sure that this isn't a solution in search of a problem?
I think this really depends on how you define problem. Some people
might think that select * from myfunc(...) limit 1 should
Andrew Dunstan [EMAIL PROTECTED] writes:
The wrinkle is that applying the tags on the fly is probably not a great
idea - the status page query is already in desperate need of overhauling
because it's too slow. So we'd need a daemon to set up the tags in the
background. But that's an
I don't know if this has come up yet but
In terms of tagging errors we might be able to use some machine
learning techniques.
There are NLP/learning systems that interpret logs. They learn over
time what is normal and what isn't and can flag things that are
abnormal.
For example,
Arturo Perez wrote:
I don't know if this has come up yet but
In terms of tagging errors we might be able to use some machine
learning techniques.
There are NLP/learning systems that interpret logs. They learn over
time what is normal and what isn't and can flag things that are
I tried to make tuplestore free up tuples that would no longer be needed
because they're older than the mark and neither random access nor rewind
capability was needed. This is important for three different purposes:
optimizing merge join to not need to materialize the entire data set,
recursive
Here is a (small) patch to give the ability to pg_dump to export only the
functions (or only one), very useful when you often develop with psql (
postgresql.8.2.3)
Usage:
pg_dump -Q function_name DATABASE export function_name
pg_dump -QDATABASE export all the functions
Students Professors,
There are only 5 days left to submit your PostgreSQL Google Summer of
Code Project:
http://www.postgresql.org/developer/summerofcode.html
If you aren't a student, but know a CS student interested in databases,
testing, GUIs, or any other OSS coding, please point them to
Now that there's a mechanism in the backend that will automatically replan
queries whenever anything changes about the referenced tables, we have to
worry about whether an automatic replan might cause surprising changes in
the behavior of a query. I looked through the available GUC settings to
Tom,
Actually, I think you don't particularly need stats for that in most
cases --- if the planner simply took note that the FK relationship
exists, it would know that each row of the FK side joins to exactly
one row of the PK side, which in typical cases is sufficient.
Is it? What about the
On Tue, 2007-03-20 at 09:03 +, Simon Riggs wrote:
We should allow the DBA to specify which groups of cols to keep
statistics on, if there is no index on that group.
That solves the combinatorial explosion problem.
I think it would be a good first step if we could just keep stats on
On Tue, Mar 20, 2007 at 11:36:09AM -0400, Andrew Dunstan wrote:
My biggest worry apart from maintenance (which doesn't matter that much
- if people don't enter the regexes they don't get the tags they want)
is that the regexes will not be specific enough, and so give false
positives on the
Gregory Stark [EMAIL PROTECTED] writes:
However I've run into something I didn't expect. It seems merge joins keep a
reference to a tuple *after* they set the mark beyond it. I'm trying to figure
out why this is necessary but I haven't absorbed all of nodeMergejoin yet.
I think at the instant
Dany DeBontridder [EMAIL PROTECTED] writes:
Usage:
pg_dump -Q function_name DATABASE export function_name
pg_dump -QDATABASE export all the functions
What of overloading? And your switch syntax seems ambiguous anyway.
btw, I see no patch here...
Martijn van Oosterhout kleptog@svana.org writes:
But I'm just sprouting ideas here, the proof is in the pudding. If the
logs are easily available (or a subset of, say the last month) then
people could play with that and see what happens...
Anyone who wants to play around can replicate what I
On Tue, 2007-03-20 at 18:12 +0100, Josh Berkus wrote:
Tom,
Actually, I think you don't particularly need stats for that in most
cases --- if the planner simply took note that the FK relationship
exists, it would know that each row of the FK side joins to exactly
one row of the PK side,
Josh Berkus josh@agliodbs.com writes:
Actually, I think you don't particularly need stats for that in most
cases --- if the planner simply took note that the FK relationship
exists, it would know that each row of the FK side joins to exactly
one row of the PK side, which in typical cases is
On Fri, Mar 09, 2007 at 04:57:18PM +, Simon Riggs wrote:
On Fri, 2007-03-09 at 11:47 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
It strikes me that allowing archive_command to be changed on the fly
might not be
Hello,
The money type is considered deprecated. I was also under the impression
it would be eventually removed. Why are we accumulating TODOs for it?
# -Make 64-bit version of the MONEY data type
# Add locale-aware MONEY type, and support multiple currencies
Jim C. Nasby [EMAIL PROTECTED] writes:
On Fri, Mar 09, 2007 at 04:57:18PM +, Simon Riggs wrote:
It's certainly a quicker fix. Unless others object, I'll set
archive_command to only be changeable at server startup.
I think the docs should also explain why it's server-start only, since
if
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
IIRC indexes can already ask to have the system recheck conditions on
returned tuples. For example GiST can return more tuples than actually
match. That's what the amopreqcheck column is for in pg_amop.
Hi,
If you are looking for a SoC idea, I have listed a couple below. I
am not sure how good of an idea they are but I have ran into the
following limitations and probably other people have as well in the
past.
1. Can user based priorities be implemented as a summer project? To
some
Hackers et al... I was wondering if there are any outstanding issues
that need to be resolved in terms of the clustered index/bitmap changes?
From the testing that I have done, plus a couple of others it is a net
win (at least from DBA space).
Sincerely,
Joshua D. Drake
--
=== The
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
But I'm just sprouting ideas here, the proof is in the pudding. If the
logs are easily available (or a subset of, say the last month) then
people could play with that and see what happens...
Anyone who wants to play
Andrew Dunstan wrote:
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
But I'm just sprouting ideas here, the proof is in the pudding. If the
logs are easily available (or a subset of, say the last month) then
people could play with that and see what happens...
On Mon, Mar 19, 2007 at 06:55:56PM -0700, Jeff Davis wrote:
On Mon, 2007-03-19 at 21:24 -0400, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
We can already keep stats for a functional index. Is there a reason we
can't keep stats for a multi-column index?
The questions that
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
But I'm just sprouting ideas here, the proof is in the pudding. If the
logs are easily available (or a subset of, say the last month) then
people could play with that
Jim C. Nasby [EMAIL PROTECTED] writes:
It might be worth coming up with a different means to store the
histogram for the multi-column case.
A separate array for each column involved seems a whole lot less
fragile than pretending we can handle mixed-type arrays.
We probably need a different
Joshua D. Drake [EMAIL PROTECTED] writes:
The money type is considered deprecated. I was also under the impression
it would be eventually removed. Why are we accumulating TODOs for it?
Because doing the TODOs would remove the reasons for deprecating it.
Whether it is actually ever going to
There are several reasons why Postgres' hash indexes currently suck,
but one of the bigger ones is that the time to build an index on a
large existing table is excessive, eg
http://archives.postgresql.org/pgsql-novice/2007-03/msg00064.php
I'm not sure if this has been discussed before, but I
On Tue, 20 Mar 2007 11:24:00 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
The money type is considered deprecated. I was also under the impression
it would be eventually removed. Why are we accumulating TODOs for it?
# -Make 64-bit version of the MONEY data type
Actually, this TODO is
D'Arcy J.M. Cain wrote:
On Tue, 20 Mar 2007 11:24:00 -0700
Joshua D. Drake [EMAIL PROTECTED] wrote:
# -Make 64-bit version of the MONEY data type
Actually, this TODO is DONE. It's in HEAD now.
That is what the - prefix denotes.
-Neil
---(end of
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Here is a paper about portable userspace threads that I just googled.
http://www.gnu.org/software/pth/rse-pmt.ps
I'm not impressed --- the list of unsolved problems is a bit too long.
One that seems a showstopper for our purposes is
Hi all;
I have been looking at the TODO and have found something that I find
sort of odd and we should probably reconsider:
One of the items under data types is:
* Add NUMERIC division operator that doesn't round?
Currently NUMERIC _rounds_ the result to the specified precision.
On Tue, 20 Mar 2007, Joshua D. Drake wrote:
Hackers et al... I was wondering if there are any outstanding issues
that need to be resolved in terms of the clustered index/bitmap changes?
From the testing that I have done, plus a couple of others it is a net
win (at least from DBA space).
Not
On Mon, Mar 19, 2007 at 06:16:57PM -0400, Luis D. García wrote:
Hello, I'm writinng again because I need to make some validation for
the incoming data (VALUES... on the INSERT-Stmt). This validation
is based on adding a TIMESTAMP and a TIME kind of data.
From the Shell I can make:
Gavin Sherry wrote:
On Tue, 20 Mar 2007, Joshua D. Drake wrote:
Hackers et al... I was wondering if there are any outstanding issues
that need to be resolved in terms of the clustered index/bitmap changes?
From the testing that I have done, plus a couple of others it is a net
win (at least
I wrote:
I'm not sure if this has been discussed before, but I suddenly realized
while responding to the above message that the reason for the awful
performance is pretty obvious: hashbuild starts with a minimum-size
index (two buckets) and repeatedly splits buckets as insertions are
done,
Chris Travers [EMAIL PROTECTED] writes:
I have been looking at the TODO and have found something that I find
sort of odd and we should probably reconsider:
One of the items under data types is:
* Add NUMERIC division operator that doesn't round?
Currently NUMERIC _rounds_ the
And the patch is so small, it is invisible (missing). ;-)
---
Dany DeBontridder wrote:
Here is a (small) patch to give the ability to pg_dump to export only the
functions (or only one), very useful when you often develop
I have read all the email from when I was on vacation. I am now fully
back at work.
---
bruce wrote:
I am back from vacation and reading email again. I should be caught up
in less than a week (2.6k emails), and easily
I'm a student and I'm planning to submit a project for Google Summer of
Code. I would like to receive feedback about to implement the vacumm
scheduling in order to allow maintenance's windows.
I have read the whole discussion about Autovacuum improvements[1]
taken in January. Alvaro Herrera
I have read the HOT discussion and wanted to give my input. The major
issue is that CREATE INDEX might require a HOT chain to be split apart
if one of the new indexed columns changed in the HOT chain.
As for the outline below, there is no way we are going to add new ALTER
TABLE and CHILL
Tom Lane skrev:
The money type is considered deprecated. I was also under the impression
it would be eventually removed. Why are we accumulating TODOs for it?
Because doing the TODOs would remove the reasons for deprecating it.
Whether it is actually ever going to disappear is not agreed
The version 5.0 of HOT WIP patch is posted on pgsql-patches. This
fixes the VACUUM FULL issue with HOT. In all the earlier versions,
I'd disabled VACUUM FULL.
When we move the HOT-chain, we move the chains but don't carry
the HOT_UPDATED or HEAP_ONLY flags and insert as many index
entries as
Dennis Bjorklund [EMAIL PROTECTED] writes:
Tom Lane skrev:
Whether it is actually ever going to disappear is not agreed upon.
What is the reason to keep it?
The words-of-one-syllable answer is that D'Arcy Cain is still willing
to put work into supporting the money type, and if it still gets
66 matches
Mail list logo
