We frequently recommend to people that they increase sort_mem while
creating btree indexes. It is reasonable to have a larger setting
for that purpose, since (1) a single backend isn't going to be doing
multiple index creations in parallel (whereas complex queries could
easily be doing multiple so
On Sat, 31 Jan 2004, Tom Lane wrote:
> So, what I'd like to do is make btree index creation pay attention to
> vacuum_mem instead of sort_mem, and rename the vacuum_mem parameter to
> some more-generic name indicating that it's used for more than just
> VACUUM. Any objections so far?
Why not cre
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sat, 31 Jan 2004, Tom Lane wrote:
>> So, what I'd like to do is make btree index creation pay attention to
>> vacuum_mem instead of sort_mem, and rename the vacuum_mem parameter to
>> some more-generic name indicating that it's used for more than
Tom Lane wrote:
Now, what should we call it instead? I haven't come up with any
compelling thoughts --- the best I can do is "big_sort_mem" or
"single_sort_mem". Surely someone out there has a better idea.
BTW, does anyone want to lobby for renaming sort_mem at the same time?
Since it's used for
On Sat, 31 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Sat, 31 Jan 2004, Tom Lane wrote:
> >> So, what I'd like to do is make btree index creation pay attention to
> >> vacuum_mem instead of sort_mem, and rename the vacuum_mem parameter to
> >> some more-gener
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW, does anyone want to lobby for renaming sort_mem at the same time?
>> Since it's used for sizing hash tables as well as sort workspace, it's
>> rather misnamed. I hesitate to rename it because of the potential for
>> confusion though.
Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> BTW, does anyone want to lobby for renaming sort_mem at the same time?
> >> Since it's used for sizing hash tables as well as sort workspace, it's
> >> rather misnamed. I hesitate to rename it because of the potentia
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Joe Conway <[EMAIL PROTECTED]> writes:
>>> Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
>>> similar?
>>
>> I'll go with these unless someone has another proposal ...
> The only confusion is that you can use mu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Joe Conway <[EMAIL PROTECTED]> writes:
> >>> Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
> >>> similar?
> >>
> >> I'll go with these unless someone has another proposal ...
>
> > The onl
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW, I am going to look at whether GUC can be persuaded to continue to
>> allow "sort_mem" as an alternate name, if we rename it. That would
>> alleviate most of the backward-compatibility issues of changing such
>> a well-known parame
Tom Lane wrote:
With this approach, old GUC names would be recognized in SHOW and SET
commands, as well as the other ways you can set a variable by name
(postgresql.conf, ALTER USER SET, etc). But only the new names would
appear in SHOW ALL or the pg_settings view. Does that seem OK?
May be rai
Tom Lane wrote:
With this approach, old GUC names would be recognized in SHOW and SET
commands, as well as the other ways you can set a variable by name
(postgresql.conf, ALTER USER SET, etc). But only the new names would
appear in SHOW ALL or the pg_settings view. Does that seem OK?
Seems OK to
Seems OK to me, in fact maybe preferred. But I wonder if we should emit
a NOTICE when old names are used with SHOW and SET commands?
A WARNING should be issued.
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Sat, 31 Jan 2004, Tom Lane wrote:
> Now, what should we call it instead? I haven't come up with any
> compelling thoughts --- the best I can do is "big_sort_mem" or
> "single_sort_mem". Surely someone out there has a better idea.
vacuuming and indexing are not too frequent database administ
Tom Lane wrote:
> After looking at the code a bit, I think the simplest solution is for
> find_option to look in a separate mapping table (mapping from old to new
> option name) if it doesn't find the given name in the main table. This
> would make lookup of "old" names a shade slower than "prefer
Jeff <[EMAIL PROTECTED]> writes:
>> On Sat, 31 Jan 2004, Tom Lane wrote:
> Well, maybe. What's in the back of my mind is that we may come
> across other cases besides CREATE INDEX and VACUUM that should use a
> "one-off" setting. I think it'd make more sense to have one
> parameter than keep on i
On Mon, 2 Feb 2004, Tom Lane wrote:
> Jeff <[EMAIL PROTECTED]> writes:
> >> On Sat, 31 Jan 2004, Tom Lane wrote:
> > Well, maybe. What's in the back of my mind is that we may come
> > across other cases besides CREATE INDEX and VACUUM that should use a
> > "one-off" setting. I think it'd make mo
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> any chance of having some kind of max_total_sort_mem setting to keep
> machines out of swap storms, or would that be a nightmare to implement?
I don't see any reasonable way to do that.
regards, tom lane
-
On Mon, 2 Feb 2004, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > any chance of having some kind of max_total_sort_mem setting to keep
> > machines out of swap storms, or would that be a nightmare to implement?
>
> I don't see any reasonable way to do that.
I didn't think th
scott.marlowe wrote:
> On Mon, 2 Feb 2004, Tom Lane wrote:
>
> > "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > > any chance of having some kind of max_total_sort_mem setting to keep
> > > machines out of swap storms, or would that be a nightmare to implement?
> >
> > I don't see any reasonable
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I didn't think there was. just hoping... :-)
> Someone asked for this in Copenhagen, and I said we can't see how to do
> it. The only idea I had as to give the first requestor 50% of the
> total, then a second query 50% of the remaining memory. Is th
Tom Lane <[EMAIL PROTECTED]> writes:
> > Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
> > similar?
>
> I'll go with these unless someone has another proposal ...
dml_sort_mem and ddl_sort_mem ?
--
greg
---(end of broadcast)
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > > Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
> > > similar?
> >
> > I'll go with these unless someone has another proposal ...
>
> dml_sort_mem and ddl_sort_mem ?
I thought about that, but didn't think DML
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> On 12 Feb 2004, Greg Stark wrote:
>> dml_sort_mem and ddl_sort_mem ?
> I like those. Are they an accurte representation of what's going on?
No, not particularly ...
regards, tom lane
---(end of broadc
On 12 Feb 2004, Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > > Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
> > > similar?
> >
> > I'll go with these unless someone has another proposal ...
>
> dml_sort_mem and ddl_sort_mem ?
I like those. Are they a
25 matches
Mail list logo
