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 g
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 the
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 upon.
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 command
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 su
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
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 develo
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_
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
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
>> w
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:
>
>
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).
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.
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 i
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 br
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
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 sudde
"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 t
"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 differen
Joshua D. Drake wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
Martijn van Oosterhout 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 happ
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 ques
Andrew Dunstan wrote:
> Tom Lane wrote:
>> Martijn van Oosterhout 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...
>>>
>>
>> A
Tom Lane wrote:
Martijn van Oosterhout 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 w
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 Po
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.
"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, s
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
http://archives.postgresql.org/pgsql-
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
> > >>
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 ex
Josh Berkus 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 sufficient.
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
Martijn van Oosterhout 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 did, which was t
"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...
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 inst
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 t
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
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
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
see
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
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
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 q
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 abnormal
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,
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 im
Ü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
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 da
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
t
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 tha
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 re
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 t
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
>>
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 o
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 ma
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 Mart
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 extr
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 ...
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm
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 w
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 T
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 ...
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoose&dt=2007-03-2
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 no
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 th
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 rea
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=mongoose&dt=2007-03-20%2006:30:01
Maybe a simple c
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 s
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 ke
65 matches
Mail list logo
