Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I turns out I have not been reviewing all patches kept during the beta
> > period for releases 7.2-7.4. I have gone though the kept emails and
> > found 37 messages that need review:
> > http://momjian.postgresql.org/cgi-bin/pgpat
Just thought of something after reading and deleting Gavin's email ...
don't we have a 'pgtune' utility, or wasn't that something someone was
working? how many settings, like fsm, can be determined by analzying a
database?
Marc G. Fournier Hub.Org Networking Services (http://www
Hello,
I'm working on a new module to handle EAN13, ISBN, ISMN, and ISSN.
The new module validates, and automatically adds the correct hyphenations of
the numbers. Also it supports the new ISBN 13 number to be used starting on
2005.
This is my first module, and it's almost done, but I'm having so
On Thu, 4 Nov 2004, Tom Lane wrote:
I'm not sure if I like this one too much ... but it would be nice if
something like this triggered a warning in the logs, maybe a feature of
pg_autovacuum itself?
autovacuum would probably be a reasonable place to put it. We don't
currently have any good way for
Neil Conway wrote:
[CC list trimmed]
On Fri, 2004-11-05 at 06:41, Tom Lane wrote:
(I'm rather interested to know whether any other SCMs have a better
solution to this problem, and if so what it is. It's not obvious how
to do better.)
Sure -- just about every "next generation" OSS version control
On Thu, 4 Nov 2004, Marc G. Fournier wrote:
>
> Moved to -hackers where this belongs :)
>
> On Fri, 5 Nov 2004, Justin Clift wrote:
>
> > Tom Lane wrote:
> >
> >> Yup. 2 < 23072, so you're losing some proportion of FSM entries.
> >> What's worse, the FSM relation table is maxed out (1000 = 10
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Moved to -hackers where this belongs :)
> On Fri, 5 Nov 2004, Justin Clift wrote:
>> Would making max_fsm_relations and max_fsm_pages dynamically update
>> themselves whilst PostgreSQL runs be useful?
Possibly, but it isn't happening in the forese
Moved to -hackers where this belongs :)
On Fri, 5 Nov 2004, Justin Clift wrote:
Tom Lane wrote:
Yup. 2 < 23072, so you're losing some proportion of FSM entries.
What's worse, the FSM relation table is maxed out (1000 = 1000) which
suggests that there are relations not being tracked at all; you
[CC list trimmed]
On Fri, 2004-11-05 at 06:41, Tom Lane wrote:
> (I'm rather interested to know whether any other SCMs have a better
> solution to this problem, and if so what it is. It's not obvious how
> to do better.)
Sure -- just about every "next generation" OSS version control tool gets
th
Hi all,
the on line doc still show the 7.4.5.
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 8: explain analyze is your friend
On Fri, 5 Nov 2004 07:02 am, Marc G. Fournier wrote:
> On Thu, 4 Nov 2004, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> why would we lose CVS history? I can physically move the files in
> >> /cvsroot to accomplish this ... just tell me what needs to move, and to
> >>
Hi,
On Thursday 04 November 2004 20:41, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > why would we lose CVS history? I can physically move the files in
> > /cvsroot to accomplish this ... just tell me what needs to move, and to
> > where ...
>
> If you physically move the f
Tom Lane wrote:
AFAICS the only nondestructive way to do this is to cvs delete and cvs
add, with a commit comment saying where the files were moved from. Then
when you are looking at them in CVS, you'd have to navigate over to the
previous location (by hand, probably; the commit comment isn't goin
On Thu, Nov 04, 2004 at 02:41:08PM -0500, Tom Lane wrote:
>
> (I'm rather interested to know whether any other SCMs have a better
> solution to this problem, and if so what it is. It's not obvious how
> to do better.)
I understood that the whole point of subversion was mostly to make
moving file
On Thu, 4 Nov 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
why would we lose CVS history? I can physically move the files in
/cvsroot to accomplish this ... just tell me what needs to move, and to
where ...
If you physically move the files, that would retroactively change t
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> why would we lose CVS history? I can physically move the files in
> /cvsroot to accomplish this ... just tell me what needs to move, and to
> where ...
If you physically move the files, that would retroactively change their
placement in back vers
On Thu, 4 Nov 2004, Alvaro Herrera wrote:
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Why not move it to src/tools, so no one gets the impression that it is
user code?
I thought about that earlier, but concluded it wasn't worth the loss of
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Can this be discussed for 8.1?
It's been discussed, and rejected, several times already. There aren't
any alternatives that are enough better than CVS to be worth the
changeover effort.
regards, tom lane
--
You are correct.
I would envision being able to alter a table "read-write" at any point.
If the index(es) on the table are completely filled from being created
in read-only mode, then the affected pages should be split with the
default fillfactor when/if a row is inserted or updated. Altering the
On Thu, 2004-11-04 at 18:15, Rod Taylor wrote:
> > At some point it would also be nice to be able to mark tables as
> > read-only and then any indexes created on that table after that would
> > have a fillfactor of 100%. Then I'd be able to load the table, alter it
> > to be read-only, then add th
On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Why not move it to src/tools, so no one gets the impression that it is
> > user code?
>
> I thought about that earlier, but concluded it wasn't worth the loss of
> CVS history.
I have cou
On Thu, 2004-11-04 at 17:59, Darren King wrote:
> In my data warehousing situation, I'd like to be able to specify that
> the indexes be as compact as possible (fillfactor = 100%) in order to
> hit as few index pages as necessary.
>
Yes, that's my intent.
> At some point it would also be nice to
> At some point it would also be nice to be able to mark tables as
> read-only and then any indexes created on that table after that would
> have a fillfactor of 100%. Then I'd be able to load the table, alter it
> to be read-only, then add the appropriate indexes that are automatically
> compacte
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I turns out I have not been reviewing all patches kept during the beta
> period for releases 7.2-7.4. I have gone though the kept emails and
> found 37 messages that need review:
> http://momjian.postgresql.org/cgi-bin/pgpatches3
> I would like to
In my data warehousing situation, I'd like to be able to specify that
the indexes be as compact as possible (fillfactor = 100%) in order to
hit as few index pages as necessary.
For summary tables there will not be any more inserts or deletions so
the index will not change either. In that case, th
Simon Riggs wrote:
> On Thu, 2004-11-04 at 16:51, Bruce Momjian wrote:
> > OK, I updated all your items.
>
> Thanks
>
> > I removed fillfactor because I thought I
> > was the only one who thought it was valuable and as I remember it was
> > mostly useful for ISAM, which we don't support. Can y
On Thu, 2004-11-04 at 16:51, Bruce Momjian wrote:
> OK, I updated all your items.
Thanks
> I removed fillfactor because I thought I
> was the only one who thought it was valuable and as I remember it was
> mostly useful for ISAM, which we don't support. Can you think of a use
> for a non-100%
Added:
* Add fillfactor to control reserved free space during index
creation
---
Kenneth Marshall wrote:
> Bruce,
>
> Just to chime in. I also agree that fillfactor is useful. I have
> been investigating
The problem is fully described in thread I mentioned earlier, Tom's
excellent explanation can be found here:
http://groups.google.com/groups?hl=cs&lr=&frame=right&th=5227028cb3449572&seekm=11390.1080964720%40sss.pgh.pa.us#link14
Oh, that thing. Well, my opinion has not changed since April --- I
On Thu, Nov 04, 2004 at 10:48:09AM -0500, Tom Lane wrote:
> Looking at the back versions, it appears this logic was put in in 7.2;
> is it possible you are remembering the behavior of older versions?
Quite likely, in fact. Thanks for clearing that up.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
Simon Riggs wrote:
>
> 4. Multiple column index statistics
>
> Allow accurate statistics to be collected on indexes that have more than
> one column, so that they are more frequently selected for use.
>
> (following on from Manfred Koizar's exploratory patch to provide
> this...)
Added.
--
OK, I updated all your items. I removed fillfactor because I thought I
was the only one who thought it was valuable and as I remember it was
mostly useful for ISAM, which we don't support. Can you think of a use
for a non-100% fillfactor?
Kuba Ouhrabka <[EMAIL PROTECTED]> writes:
> The problem is fully described in thread I mentioned earlier, Tom's
> excellent explanation can be found here:
> http://groups.google.com/groups?hl=cs&lr=&frame=right&th=5227028cb3449572&seekm=11390.1080964720%40sss.pgh.pa.us#link14
Oh, that thing. Wel
Hi,
I think it's most likely that there were also old transactions in the
current database. Only the shared tables (pg_shadow, pg_database,
pg_group) are vacuumed using a cutoff that depends on non-local
transactions.
in my case, there are really no old transactions in current database.
Looking at
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Updated TODO:
>
> > * Allow the creation of bitmap indexes which can be quickly combined
> > with other bitmap indexes
>
> This TODO item description is fundamentally misleading.
>
> The point was *not* about making "bitmap indexe
My suggestion is to add some more logic to vacuum to get correct oldest
xmin - local to current database.
If you read the code a little more closely, you'd see that it already does.
regards, tom lane
Could you pls tell what has changed since 7.4? I'm not able to find it...
Thanks
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, Nov 04, 2004 at 10:00:23AM -0500, Tom Lane wrote:
>> If you read the code a little more closely, you'd see that it already does.
> Hmm, so obviously I was confused in my other message. But I've seen
> the same sort of effect as the OP: transac
On Thu, Nov 04, 2004 at 10:00:23AM -0500, Tom Lane wrote:
>
> If you read the code a little more closely, you'd see that it already does.
Hmm, so obviously I was confused in my other message. But I've seen
the same sort of effect as the OP: transactions in another database
on the same back end s
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> Just for quick note, it seems query 19 takes forever. Have you
> >> successfully run Q19?
>
> > Here is the more detailed info. The query was not finished within 3
> > days and was canceled on a Dual Xeon 2.8GHz with 2.5GB RAM running
> > Linux. Post
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> Just for quick note, it seems query 19 takes forever. Have you
>> successfully run Q19?
> Here is the more detailed info. The query was not finished within 3
> days and was canceled on a Dual Xeon 2.8GHz with 2.5GB RAM running
> Linux. PostgreSQL is 7.4.
Kuba Ouhrabka <[EMAIL PROTECTED]> writes:
> My suggestion is to add some more logic to vacuum to get correct oldest
> xmin - local to current database.
If you read the code a little more closely, you'd see that it already does.
regards, tom lane
--
On Thu, 4 Nov 2004, Simon Riggs wrote:
> REF INTEGRITY
>
> ...Didn't we just get rid of deferred triggers?? Perhaps I read that
> wrong.
We got rid of deferred referential actions. Constraint check triggers
for referential integrity (insert/update to fk table, NO ACTION on pk
table) are still d
On Thu, Nov 04, 2004 at 09:31:05AM +0100, Kuba Ouhrabka wrote:
> initial data loading are essential tasks. The only solution I can see
> now, is to have several database clusters on the server in order to have
> completly separated databases...
We actually do that, for the reasons you say, plus be
On Thu, 2004-11-04 at 09:31, Simon Riggs wrote:
> A few minor typos/notes:
>
> INDEXES
>
> 1. On 2nd bullet...
> "The main difficulty with this item is the problem of creating an index
> that can spam more than one table."
>
> should be span, not spam
>
> 2. On 6th bullet
> * "Use index to re
Tom Lane wrote:
> Thomas Hallgren <[EMAIL PROTECTED]> writes:
>
>>The Rationale for my opinion is that since there is a need to accomplish
>>what Gaetano needs, there should be declarative power to express it and
>>thus, prevent "unsafe" designs. We need a way to declare a function
>>"stable with n
Hi,
On Thu, Nov 04, 2004 at 11:26:41AM +0100, [EMAIL PROTECTED] wrote:
>
> I would like to hear your opinion and whether anyone is interested in
> helping.
I'd appreciate any kind of hints, helping me to understand the
modules/components and sources of each.
Regards,
Yann
-
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: 04 November 2004 10:27
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Contribute to the development of PostgreSQL
>
> Dear Folks,
>
> Sometime ago I posted a message rega
Dear Bruce,
I turns out I have not been reviewing all patches kept during the beta
period for releases 7.2-7.4. I have gone though the kept emails and
found 37 messages that need review:
http://momjian.postgresql.org/cgi-bin/pgpatches3
I'm to submit a small patch to add missing include files plus
Dear Folks,
Sometime ago I posted a message regarding learning to develop and
contribute to the development of PostgreSQL. I started my journey with
downloading the sources and take a look at the bits and pieces of the
code. As I was expecting it to be, my journey was and still is ponderous
one. I
Robert,
I think the guidelines are fairly clear on what types of functions should be
declared with which types. But the key is that these are guidelines, not hard
and fast rules, since there may be times when you need to ignore them.
In 7.4 they where indeed guidelines. In 8.x the semantics o
> > > Hi Tatsuo,
> > >
> > > I've made a new release:
> > > http://prdownloads.sourceforge.net/osdldbt/dbt3-v1.5.tar.gz?download
> > >
> > > Let me know if there are any problems.
> >
> > Thanks!
>
> Just for quick note, it seems query 19 takes forever. Have you
> successfully run Q19?
Here
A few minor typos/notes:
INDEXES
1. On 2nd bullet...
"The main difficulty with this item is the problem of creating an index
that can spam more than one table."
should be span, not spam
2. On 6th bullet
* "Use index to restrict rows returned by multi-key index when used
with non-consecuti
> > Hi Tatsuo,
> >
> > I've made a new release:
> > http://prdownloads.sourceforge.net/osdldbt/dbt3-v1.5.tar.gz?download
> >
> > Let me know if there are any problems.
>
> Thanks!
Just for quick note, it seems query 19 takes forever. Have you
successfully run Q19?
--
Tatsuo Ishii
-
Hi,
we use 7.4 and suffer from table and index bloat. I tracked down the
issue to vacuum using GetOldestXmin() which returns the oldest xmin of
any database in cluster, not xmin of the current database. Yes, I've
read the thread about this issue called "Problems Vacuumi'ng" - April 2004
http://grou
54 matches
Mail list logo
