public inbox for [email protected]
help / color / mirror / Atom feedpg_autovacuum is nice ... but ...
24+ messages / 10 participants
[nested] [flat]
* pg_autovacuum is nice ... but ...
@ 2004-11-03 20:10 Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Marc G. Fournier @ 2004-11-03 20:10 UTC (permalink / raw)
To: pgsql-www
Dave and I have been spending today trying to narrow down why things are
so slow ... using the current index.php as a test bed, since its simple
enough to debug, we removed the (require) that was at the top, and pulled
the file in directly, so that there was no 'reading from the file system'
issue involved ... still slow as molasses ... comment out the database
connections, zippy as can be ... of course, no data, since the queries
failed ... but ...
Do a vacuum full analyze on the two databases being called, and load time
went from 2.4sec to .46sec:
www# time fetch http://www.postgresql.org/index.php
fetch: http://www.postgresql.org/index.php: size of remote file is not known
index.php 24 kB 2737 kBps
0.000u 0.077s 0:00.46 15.2%
I've been able to drop Alexey's down by about half, from 5sec to 2.5sec
(based on multiple loads, the lowest I've seen is 1.91sec) ... but, at
least now when I go to look at the site in the browser, it isn't abysmally
slow, only slow ...
Random samplings on index.php for the current site, I'm getting as low as
.19sec ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
@ 2004-11-03 22:29 ` Justin Clift <[email protected]>
2004-11-03 22:36 ` Re: pg_autovacuum is nice ... but ... Joshua D. Drake <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
0 siblings, 2 replies; 24+ messages in thread
From: Justin Clift @ 2004-11-03 22:29 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: pgsql-www
Marc G. Fournier wrote:
<snip>
> Do a vacuum full analyze on the two databases being called, and load
> time went from 2.4sec to .46sec:
Hmmmm, is there any chance your Free Space Map settings aren't high enough?
Regards and best wishes,
Justin Clift
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
@ 2004-11-03 22:36 ` Joshua D. Drake <[email protected]>
2004-11-04 00:21 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
1 sibling, 1 reply; 24+ messages in thread
From: Joshua D. Drake @ 2004-11-03 22:36 UTC (permalink / raw)
To: Justin Clift <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; pgsql-www
Justin Clift wrote:
> Marc G. Fournier wrote:
> <snip>
>
>> Do a vacuum full analyze on the two databases being called, and load
>> time went from 2.4sec to .46sec:
>
>
> Hmmmm, is there any chance your Free Space Map settings aren't high enough?
>
I could be wrong but my understanding is that pg_autovacuum won't vacuum
system tables so eventually you still need to perform a full vacuum (not
neccessarily a vacuum full).
Could this be the issue?
> Regards and best wishes,
>
> Justin Clift
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
--
Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [email protected] - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachments:
[text/x-vcard] jd.vcf (640B, 2-jd.vcf)
download | inline:
begin:vcard
fn:Joshua D. Drake
n:Drake;Joshua D.
org:Command Prompt, Inc.
adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA
email;internet:[email protected]
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0334
note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl.
x-mozilla-html:FALSE
url:http://www.commandprompt.com/
version:2.1
end:vcard
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-03 22:36 ` Re: pg_autovacuum is nice ... but ... Joshua D. Drake <[email protected]>
@ 2004-11-04 00:21 ` Marc G. Fournier <[email protected]>
0 siblings, 0 replies; 24+ messages in thread
From: Marc G. Fournier @ 2004-11-04 00:21 UTC (permalink / raw)
To: Joshua D. Drake <[email protected]>; +Cc: Justin Clift <[email protected]>; Marc G. Fournier <[email protected]>; pgsql-www
On Wed, 3 Nov 2004, Joshua D. Drake wrote:
> Justin Clift wrote:
>> Marc G. Fournier wrote:
>> <snip>
>>
>>> Do a vacuum full analyze on the two databases being called, and load time
>>> went from 2.4sec to .46sec:
>>
>>
>> Hmmmm, is there any chance your Free Space Map settings aren't high enough?
>>
>
> I could be wrong but my understanding is that pg_autovacuum won't vacuum
> system tables so eventually you still need to perform a full vacuum (not
> neccessarily a vacuum full).
>
> Could this be the issue?
I just setup a weekly cron to do a vacuum full ... I didn't realize that
pg_autovacuum didn't catch it all, except, of course, I should have clued
in when we had that fun with the banner database, where an index on a 12
row table was faster then no index :)
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
@ 2004-11-04 00:20 ` Marc G. Fournier <[email protected]>
2004-11-04 01:15 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
1 sibling, 2 replies; 24+ messages in thread
From: Marc G. Fournier @ 2004-11-04 00:20 UTC (permalink / raw)
To: Justin Clift <[email protected]>; +Cc: pgsql-www
On Thu, 4 Nov 2004, Justin Clift wrote:
> Marc G. Fournier wrote:
> <snip>
>> Do a vacuum full analyze on the two databases being called, and load time
>> went from 2.4sec to .46sec:
>
> Hmmmm, is there any chance your Free Space Map settings aren't high enough?
I posted once asking about that, but got no responses :)
Here is a vacuum verbose on gborg's database:
INFO: free space map: 1000 relations, 7454 pages stored; 23072 total pages needed
DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared memory.
and this is portal:
INFO: free space map: 1000 relations, 7425 pages stored; 23024 total pages needed
DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared memory.
so, you tell me ... should I increase them? I haven't been able to find
any docs that talk about this :(
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
@ 2004-11-04 01:15 ` Justin Clift <[email protected]>
2004-11-04 01:50 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
1 sibling, 1 reply; 24+ messages in thread
From: Justin Clift @ 2004-11-04 01:15 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: pgsql-www
Marc G. Fournier wrote:
<snip>
> I posted once asking about that, but got no responses :)
>
> Here is a vacuum verbose on gborg's database:
>
> INFO: free space map: 1000 relations, 7454 pages stored; 23072 total
> pages needed
> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB
> shared memory.
> and this is portal:
>
> INFO: free space map: 1000 relations, 7425 pages stored; 23024 total
> pages needed
> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB
> shared memory.
>
> so, you tell me ... should I increase them? I haven't been able to find
> any docs that talk about this :(
Hmmmm, what are the fsm settings for that postgresql.conf?
:)
Regards and best wishes,
Justin Clift
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:15 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
@ 2004-11-04 01:50 ` Marc G. Fournier <[email protected]>
2004-11-04 03:32 ` Re: pg_autovacuum is nice ... but ... Robert Treat <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Marc G. Fournier @ 2004-11-04 01:50 UTC (permalink / raw)
To: Justin Clift <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; pgsql-www
On Thu, 4 Nov 2004, Justin Clift wrote:
> Marc G. Fournier wrote:
> <snip>
>> I posted once asking about that, but got no responses :)
>>
>> Here is a vacuum verbose on gborg's database:
>>
>> INFO: free space map: 1000 relations, 7454 pages stored; 23072 total pages
>> needed
>> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared
>> memory.
>> and this is portal:
>>
>> INFO: free space map: 1000 relations, 7425 pages stored; 23024 total pages
>> needed
>> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared
>> memory.
>>
>> so, you tell me ... should I increase them? I haven't been able to find
>> any docs that talk about this :(
>
> Hmmmm, what are the fsm settings for that postgresql.conf?
Ummmm ... the same as what the DETAIL line above states? :)
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:15 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 01:50 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
@ 2004-11-04 03:32 ` Robert Treat <[email protected]>
0 siblings, 0 replies; 24+ messages in thread
From: Robert Treat @ 2004-11-04 03:32 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Justin Clift <[email protected]>; pgsql-www
On Wednesday 03 November 2004 20:50, Marc G. Fournier wrote:
> On Thu, 4 Nov 2004, Justin Clift wrote:
> > Marc G. Fournier wrote:
> >> Here is a vacuum verbose on gborg's database:
> >>
> >> INFO: free space map: 1000 relations, 7454 pages stored; 23072 total
> >> pages needed
> >> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB
> >> shared memory.
> >> and this is portal:
> >>
> >> INFO: free space map: 1000 relations, 7425 pages stored; 23024 total
> >> pages needed
> >> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB
> >> shared memory.
> >>
> >> so, you tell me ... should I increase them? I haven't been able to find
> >> any docs that talk about this :(
> >
Those numbers don't look right, but I'd say increase your max_fsm_pages to
25000 and your max_fsm_relations to 1250. Don't forget to HUP.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
@ 2004-11-04 01:53 ` Tom Lane <[email protected]>
2004-11-04 02:33 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
1 sibling, 2 replies; 24+ messages in thread
From: Tom Lane @ 2004-11-04 01:53 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Justin Clift <[email protected]>; pgsql-www
"Marc G. Fournier" <[email protected]> writes:
> Here is a vacuum verbose on gborg's database:
> INFO: free space map: 1000 relations, 7454 pages stored; 23072 total pages needed
> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared memory.
> and this is portal:
> INFO: free space map: 1000 relations, 7425 pages stored; 23024 total pages needed
> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared memory.
> so, you tell me ... should I increase them?
Yup. 20000 < 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 have
no idea how much space is getting leaked in those.
You can determine the number of relations potentially needing FSM
entries by
select count(*) from pg_class where relkind in ('r','i','t');
--- sum over all databases in the cluster to get the right result.
Once you've fixed max_fsm_relations, do vacuums in all databases, and
then vacuum verbose should give you a usable lower bound for
max_fsm_pages.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
@ 2004-11-04 02:33 ` Marc G. Fournier <[email protected]>
1 sibling, 0 replies; 24+ messages in thread
From: Marc G. Fournier @ 2004-11-04 02:33 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Justin Clift <[email protected]>; pgsql-www
On Wed, 3 Nov 2004, Tom Lane wrote:
> "Marc G. Fournier" <[email protected]> writes:
>> Here is a vacuum verbose on gborg's database:
>
>> INFO: free space map: 1000 relations, 7454 pages stored; 23072 total pages needed
>> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared memory.
>> and this is portal:
>
>> INFO: free space map: 1000 relations, 7425 pages stored; 23024 total pages needed
>> DETAIL: Allocated FSM size: 1000 relations + 20000 pages = 178 kB shared memory.
>
>> so, you tell me ... should I increase them?
>
> Yup. 20000 < 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 have
> no idea how much space is getting leaked in those.
'k, increased to 25000/1500, and am runninga vacuum on all databases now
...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
@ 2004-11-04 22:11 ` Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
1 sibling, 1 reply; 24+ messages in thread
From: Justin Clift @ 2004-11-04 22:11 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; pgsql-www
Tom Lane wrote:
<snip>
> Yup. 20000 < 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 have
> no idea how much space is getting leaked in those.
>
> You can determine the number of relations potentially needing FSM
> entries by
> select count(*) from pg_class where relkind in ('r','i','t');
> --- sum over all databases in the cluster to get the right result.
>
> Once you've fixed max_fsm_relations, do vacuums in all databases, and
> then vacuum verbose should give you a usable lower bound for
> max_fsm_pages.
Would making max_fsm_relations and max_fsm_pages dynamically update
themselves whilst PostgreSQL runs be useful? Sounds like they're the
kind of things that many people would receive maximum benefit if
PostgreSQL altered these settings as needed itself.
?
Regards and best wishes,
Justin Clift
> regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
@ 2004-11-04 22:26 ` Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 23:09 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gavin Sherry <[email protected]>
2004-11-29 02:03 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Bruce Momjian <[email protected]>
0 siblings, 3 replies; 24+ messages in thread
From: Marc G. Fournier @ 2004-11-04 22:26 UTC (permalink / raw)
To: Justin Clift <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
Moved to -hackers where this belongs :)
On Fri, 5 Nov 2004, Justin Clift wrote:
> Tom Lane wrote:
> <snip>
>> Yup. 20000 < 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 have
>> no idea how much space is getting leaked in those.
>>
>> You can determine the number of relations potentially needing FSM
>> entries by
>> select count(*) from pg_class where relkind in ('r','i','t');
>> --- sum over all databases in the cluster to get the right result.
>>
>> Once you've fixed max_fsm_relations, do vacuums in all databases, and
>> then vacuum verbose should give you a usable lower bound for
>> max_fsm_pages.
>
> Would making max_fsm_relations and max_fsm_pages dynamically update
> themselves whilst PostgreSQL runs be useful? Sounds like they're the
> kind of things that many people would receive maximum benefit if
> PostgreSQL altered these settings as needed itself.
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?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
@ 2004-11-04 22:44 ` Tom Lane <[email protected]>
2004-11-05 02:19 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-05 12:00 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gaetano Mendola <[email protected]>
2004-11-08 16:40 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Jan Wieck <[email protected]>
2 siblings, 3 replies; 24+ messages in thread
From: Tom Lane @ 2004-11-04 22:44 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Justin Clift <[email protected]>; [email protected]
"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 foreseeable future, for the same
reason that we don't auto-update shared_buffers and the other shared
memory sizing parameters: we can't resize shared memory on the fly.
> 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 autovacuum to get at the information,
but I suppose that an integrated autovacuum daemon could do so.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
@ 2004-11-05 02:19 ` Marc G. Fournier <[email protected]>
2 siblings, 0 replies; 24+ messages in thread
From: Marc G. Fournier @ 2004-11-05 02:19 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Justin Clift <[email protected]>; [email protected]
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 autovacuum to get at the information,
> but I suppose that an integrated autovacuum daemon could do so.
You had mentioned doing the select on pg_class for the relations variable
... pg_autovacuum could just as easily do that as part of its start up
routine, no? when it 'loads' all the table information?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
@ 2004-11-05 12:00 ` Gaetano Mendola <[email protected]>
2004-11-05 12:33 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Neil Conway <[email protected]>
2 siblings, 1 reply; 24+ messages in thread
From: Gaetano Mendola @ 2004-11-05 12:00 UTC (permalink / raw)
To: Tom Lane <[email protected]>
Tom Lane wrote:
> "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 foreseeable future, for the same
> reason that we don't auto-update shared_buffers and the other shared
> memory sizing parameters: we can't resize shared memory on the fly.
Right but we can create a new segment and use it too. I don't know how
these segments are used but I used to do it in the past, of course you have
to create a memory manager that handle not ccntinuous segments.
Of course this only if the effort to do it can justify the man power working
on it.
Regards
Gaetano Mendola
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-05 12:00 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gaetano Mendola <[email protected]>
@ 2004-11-05 12:33 ` Neil Conway <[email protected]>
2004-11-05 12:48 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gaetano Mendola <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Neil Conway @ 2004-11-05 12:33 UTC (permalink / raw)
To: Gaetano Mendola <[email protected]>; +Cc: Tom Lane <[email protected]>; [email protected]
Gaetano Mendola wrote:
> Right but we can create a new segment and use it too. I don't know how
> these segments are used but I used to do it in the past, of course you have
> to create a memory manager that handle not ccntinuous segments.
The TelegraphCQ folks have already done this:
http://archives.postgresql.org/pgsql-hackers/2003-05/msg00336.php
I haven't had a chance to look at the patch, though.
-Neil
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-05 12:00 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gaetano Mendola <[email protected]>
2004-11-05 12:33 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Neil Conway <[email protected]>
@ 2004-11-05 12:48 ` Gaetano Mendola <[email protected]>
2004-11-05 17:39 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gaetano Mendola <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Gaetano Mendola @ 2004-11-05 12:48 UTC (permalink / raw)
To: Neil Conway <[email protected]>
Neil Conway wrote:
> Gaetano Mendola wrote:
>
>> Right but we can create a new segment and use it too. I don't know how
>> these segments are used but I used to do it in the past, of course you
>> have
>> to create a memory manager that handle not ccntinuous segments.
>
>
> The TelegraphCQ folks have already done this:
>
> http://archives.postgresql.org/pgsql-hackers/2003-05/msg00336.php
>
> I haven't had a chance to look at the patch, though.
Not bad, however that post is more than one year old. Implement a resizable
shared memory could really improve postgres performances ?
Regards
Gaetano Mendola
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-05 12:00 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gaetano Mendola <[email protected]>
2004-11-05 12:33 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Neil Conway <[email protected]>
2004-11-05 12:48 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Gaetano Mendola <[email protected]>
@ 2004-11-05 17:39 ` Gaetano Mendola <[email protected]>
0 siblings, 0 replies; 24+ messages in thread
From: Gaetano Mendola @ 2004-11-05 17:39 UTC (permalink / raw)
To: Robert Treat <[email protected]>; +Cc: Neil Conway <[email protected]>; [email protected] <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Treat wrote:
| On Friday 05 November 2004 07:48, Gaetano Mendola wrote:
|
|>Neil Conway wrote:
|> > Gaetano Mendola wrote:
|> >> Right but we can create a new segment and use it too. I don't know how
|> >> these segments are used but I used to do it in the past, of course you
|> >> have
|> >> to create a memory manager that handle not ccntinuous segments.
|> >
|> > The TelegraphCQ folks have already done this:
|> >
|> > http://archives.postgresql.org/pgsql-hackers/2003-05/msg00336.php
|> >
|> > I haven't had a chance to look at the patch, though.
|>
|>Not bad, however that post is more than one year old. Implement a resizable
|>shared memory could really improve postgres performances ?
|>
|
|
| Well it certainly would in the sense that we could make the database a little
| more self tuning.
Yes, but someone ( I do not remember who in this list ) is scared about to be "paged" during
the night because the DB is slow because a planned changed autonomously. Unfortunatelly this
is the "major" argument ( I do not understand why ) against have a database self tuning.
Regards
Gaetano Mendola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBi7qz7UpzwH2SGd4RAtaUAKC2Fij5hA9FF+TxFEGBq72LSGahpgCg4+D3
OTeNKU02YK8OgsJCaODZLn0=
=CI+E
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
@ 2004-11-08 16:40 ` Jan Wieck <[email protected]>
2004-11-08 18:05 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2 siblings, 1 reply; 24+ messages in thread
From: Jan Wieck @ 2004-11-08 16:40 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Justin Clift <[email protected]>; [email protected]
On 11/4/2004 5:44 PM, Tom Lane wrote:
> "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 foreseeable future, for the same
> reason that we don't auto-update shared_buffers and the other shared
> memory sizing parameters: we can't resize shared memory on the fly.
>
>> 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 autovacuum to get at the information,
> but I suppose that an integrated autovacuum daemon could do so.
Don't know why this must be an "integrated" autovacuum. Can't the info
about the FSM usage be presented as system views?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [email protected] #
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-08 16:40 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Jan Wieck <[email protected]>
@ 2004-11-08 18:05 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 24+ messages in thread
From: Tom Lane @ 2004-11-08 18:05 UTC (permalink / raw)
To: Jan Wieck <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Justin Clift <[email protected]>; [email protected]
Jan Wieck <[email protected]> writes:
> On 11/4/2004 5:44 PM, Tom Lane wrote:
>> autovacuum would probably be a reasonable place to put it. We don't
>> currently have any good way for autovacuum to get at the information,
>> but I suppose that an integrated autovacuum daemon could do so.
> Don't know why this must be an "integrated" autovacuum. Can't the info
> about the FSM usage be presented as system views?
No doubt, but that's not free either --- it'd still need supporting
code in the backend.
regards, tom lane
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
@ 2004-11-04 23:09 ` Gavin Sherry <[email protected]>
2 siblings, 0 replies; 24+ messages in thread
From: Gavin Sherry @ 2004-11-04 23:09 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Justin Clift <[email protected]>; Tom Lane <[email protected]>; [email protected]
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:
> > <snip>
> >> Yup. 20000 < 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 have
> >> no idea how much space is getting leaked in those.
> >>
> >> You can determine the number of relations potentially needing FSM
> >> entries by
> >> select count(*) from pg_class where relkind in ('r','i','t');
> >> --- sum over all databases in the cluster to get the right result.
> >>
> >> Once you've fixed max_fsm_relations, do vacuums in all databases, and
> >> then vacuum verbose should give you a usable lower bound for
> >> max_fsm_pages.
> >
> > Would making max_fsm_relations and max_fsm_pages dynamically update
> > themselves whilst PostgreSQL runs be useful? Sounds like they're the
> > kind of things that many people would receive maximum benefit if
> > PostgreSQL altered these settings as needed itself.
>
> 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?
Without a bit of hacking, its hard to increase the size of the free
space map dynamically. This is because the free space map resides in
shared memory and its the reason why the FSM GUC vars can only be changed
on postmaster restart -- because its at that time we can calculate how
much shared memory we need (for caching, fsm, other global resources) and
allocate it.
I think a contrib script which ran through each database and generated
some optimal FSM settings for a target database would be a good medium
term solution.
Thanks,
Gavin
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
@ 2004-11-29 02:03 ` Bruce Momjian <[email protected]>
2004-11-29 06:13 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2 siblings, 1 reply; 24+ messages in thread
From: Bruce Momjian @ 2004-11-29 02:03 UTC (permalink / raw)
To: Marc G. Fournier <[email protected]>; +Cc: Justin Clift <[email protected]>; Tom Lane <[email protected]>; [email protected]
Should I add a TODO to warn if FSM values are too small? Is that doable?
---------------------------------------------------------------------------
Marc G. Fournier wrote:
>
> Moved to -hackers where this belongs :)
>
> On Fri, 5 Nov 2004, Justin Clift wrote:
>
> > Tom Lane wrote:
> > <snip>
> >> Yup. 20000 < 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 have
> >> no idea how much space is getting leaked in those.
> >>
> >> You can determine the number of relations potentially needing FSM
> >> entries by
> >> select count(*) from pg_class where relkind in ('r','i','t');
> >> --- sum over all databases in the cluster to get the right result.
> >>
> >> Once you've fixed max_fsm_relations, do vacuums in all databases, and
> >> then vacuum verbose should give you a usable lower bound for
> >> max_fsm_pages.
> >
> > Would making max_fsm_relations and max_fsm_pages dynamically update
> > themselves whilst PostgreSQL runs be useful? Sounds like they're the
> > kind of things that many people would receive maximum benefit if
> > PostgreSQL altered these settings as needed itself.
>
> 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?
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: [email protected] Yahoo!: yscrappy ICQ: 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-29 02:03 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Bruce Momjian <[email protected]>
@ 2004-11-29 06:13 ` Justin Clift <[email protected]>
2004-11-29 13:13 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Bruce Momjian <[email protected]>
0 siblings, 1 reply; 24+ messages in thread
From: Justin Clift @ 2004-11-29 06:13 UTC (permalink / raw)
To: Bruce Momjian <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; [email protected]
Bruce Momjian wrote:
> Should I add a TODO to warn if FSM values are too small? Is that doable?
It sounds like it should be, and it would be a valuable pointer to
people, so yep.
Any idea who'd be interested in claiming it?
Regards and best wishes,
Justin Clift
^ permalink raw reply [nested|flat] 24+ messages in thread
* Re: [pgsql-www] pg_autovacuum is nice ... but ...
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 00:20 ` Re: pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-04 01:53 ` Re: pg_autovacuum is nice ... but ... Tom Lane <[email protected]>
2004-11-04 22:11 ` Re: pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
2004-11-04 22:26 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-29 02:03 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Bruce Momjian <[email protected]>
2004-11-29 06:13 ` Re: [pgsql-www] pg_autovacuum is nice ... but ... Justin Clift <[email protected]>
@ 2004-11-29 13:13 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 24+ messages in thread
From: Bruce Momjian @ 2004-11-29 13:13 UTC (permalink / raw)
To: Justin Clift <[email protected]>; +Cc: Marc G. Fournier <[email protected]>; Tom Lane <[email protected]>; [email protected]
Justin Clift wrote:
> Bruce Momjian wrote:
> > Should I add a TODO to warn if FSM values are too small? Is that doable?
>
> It sounds like it should be, and it would be a valuable pointer to
> people, so yep.
>
> Any idea who'd be interested in claiming it?
Turns out it was already on the TODO list:
* Allow free space map to be auto-sized or warn when it is too small
The free space map is in shared memory so resizing is difficult.
--
Bruce Momjian | http://candle.pha.pa.us
[email protected] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
^ permalink raw reply [nested|flat] 24+ messages in thread
end of thread, other threads:[~2004-11-29 13:13 UTC | newest]
Thread overview: 24+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-11-03 20:10 pg_autovacuum is nice ... but ... Marc G. Fournier <[email protected]>
2004-11-03 22:29 ` Justin Clift <[email protected]>
2004-11-03 22:36 ` Joshua D. Drake <[email protected]>
2004-11-04 00:21 ` Marc G. Fournier <[email protected]>
2004-11-04 00:20 ` Marc G. Fournier <[email protected]>
2004-11-04 01:15 ` Justin Clift <[email protected]>
2004-11-04 01:50 ` Marc G. Fournier <[email protected]>
2004-11-04 03:32 ` Robert Treat <[email protected]>
2004-11-04 01:53 ` Tom Lane <[email protected]>
2004-11-04 02:33 ` Marc G. Fournier <[email protected]>
2004-11-04 22:11 ` Justin Clift <[email protected]>
2004-11-04 22:26 ` Marc G. Fournier <[email protected]>
2004-11-04 22:44 ` Tom Lane <[email protected]>
2004-11-05 02:19 ` Marc G. Fournier <[email protected]>
2004-11-05 12:00 ` Gaetano Mendola <[email protected]>
2004-11-05 12:33 ` Neil Conway <[email protected]>
2004-11-05 12:48 ` Gaetano Mendola <[email protected]>
2004-11-05 17:39 ` Gaetano Mendola <[email protected]>
2004-11-08 16:40 ` Jan Wieck <[email protected]>
2004-11-08 18:05 ` Tom Lane <[email protected]>
2004-11-04 23:09 ` Gavin Sherry <[email protected]>
2004-11-29 02:03 ` Bruce Momjian <[email protected]>
2004-11-29 06:13 ` Justin Clift <[email protected]>
2004-11-29 13:13 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox