[EMAIL PROTECTED] (Tom Lane) writes:
> Chris Browne <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Bruce Momjian) writes:
>>> I have seen no one do peroformance testing of this, so it seems it
>>> will have to wait for 8.4.
>
>> I didn't have time...
>
>> (e.g. - we've got a case where dropping
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
>> I have seen no one do peroformance testing of this, so it seems it
>> will have to wait for 8.4.
> I didn't have time...
> (e.g. - we've got a case where dropping the threshold to ~900 bytes
> would give us a
[EMAIL PROTECTED] (Bruce Momjian) writes:
> I have seen no one do peroformance testing of this, so it seems it
> will have to wait for 8.4.
I didn't have time...
I'll see if I can find a decent place to document how to tweak the
threshold, as that seems like it could be worth doing in cases where
I have seen no one do peroformance testing of this, so it seems it will
have to wait for 8.4.
---
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > What I would definitely like to see for 8.3 is some perfo
Not just EDB :-)
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Chris Browne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 04, 2007 10:07 PM Eastern Standard Time
To: pgsql-hackers@postgresql.org
Subject:Re: [HACKERS] Modifying TOAST thresholds
[EMAIL
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Tom Lane) writes:
>> What I would definitely like to see for 8.3 is some performance testing
>> done to determine whether we ought to change the current defaults.
>> (Both TOAST_TUPLES_PER_PAGE and EXTERN_TUPLES_PER_PAGE ought to be look
Patch rejected, since we have decided we need to have this as part of
CREATE/ALTER table, rather than a GUC.
---
Chris Browne wrote:
> [EMAIL PROTECTED] (Tom Lane) writes:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> W
[EMAIL PROTECTED] (Tom Lane) writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> The big question is whether this is for 8.3 or 8.4.
>
> What I would definitely like to see for 8.3 is some performance testing
> done to determine whether we ought to change the current defaults.
> (Both TOAST_TUPL
"Tom Lane" <[EMAIL PROTECTED]> writes:
> What I would definitely like to see for 8.3 is some performance testing
> done to determine whether we ought to change the current defaults.
> (Both TOAST_TUPLES_PER_PAGE and EXTERN_TUPLES_PER_PAGE ought to be looked
> at.)
It will take some thinking befor
Simon Riggs wrote:
> On Wed, 2007-04-04 at 16:26 -0400, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Simon Riggs wrote:
> > >> Having both default GUC and individual table-level WITH parameters seems
> > >> like the best way to me.
> >
> > > Agreed.
> >
> > There's an extre
On Wed, 2007-04-04 at 16:26 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> Having both default GUC and individual table-level WITH parameters seems
> >> like the best way to me.
>
> > Agreed.
>
> There's an extremely good reason not to have a GUC va
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Having both default GUC and individual table-level WITH parameters seems
>> like the best way to me.
> Agreed.
There's an extremely good reason not to have a GUC variable, which is
that changes in it would fail to reflect into deci
Simon Riggs wrote:
> On Mon, 2007-04-02 at 22:23 -0400, Tom Lane wrote:
> > Chris Browne <[EMAIL PROTECTED]> writes:
> > > [EMAIL PROTECTED] (Tom Lane) writes:
> > >> ... tuning the TOAST parameters seems like
> > >> something we understand well enough already, we just need to put some
> > >> cycle
On Mon, 2007-04-02 at 22:23 -0400, Tom Lane wrote:
> Chris Browne <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] (Tom Lane) writes:
> >> ... tuning the TOAST parameters seems like
> >> something we understand well enough already, we just need to put some
> >> cycles into testing different altern
Tom,
On 4/3/07 7:15 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> BTW, it strikes me that a GUC variable is quite the wrong way to go
> about this. The right way is a table storage parameter, a la FILLFACTOR,
> so that it can be set on a per-table basis. That would also give us a
> chance to fix
Chris Browne <[EMAIL PROTECTED]> writes:
> Here's a "drafty" patch that *tries* to do this using a GUC variable;
> it passes some interactive testing.
BTW, it strikes me that a GUC variable is quite the wrong way to go
about this. The right way is a table storage parameter, a la FILLFACTOR,
so th
> > ... should we revel
> > in configurability, and allow CREATE TABLE/ALTER TABLE behavior to
> > vary depending on the current threshold setting? We'd have to fix
the
> > toaster routines to not try to push stuff out-of-line when there is
no
> > out-of-line to push to ... but I think we prob
[EMAIL PROTECTED] (Tom Lane) writes:
> Chris Browne <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Tom Lane) writes:
>>> ... tuning the TOAST parameters seems like
>>> something we understand well enough already, we just need to put some
>>> cycles into testing different alternatives. I would h
I wrote:
> ... should we revel
> in configurability, and allow CREATE TABLE/ALTER TABLE behavior to vary
> depending on the current threshold setting? We'd have to fix the
> toaster routines to not try to push stuff out-of-line when there is no
> out-of-line to push to ... but I think we probably
I wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Is there any reason to experiment with this? I would have thought we would
>> divorce TOAST_MAX_CHUNK_SIZE from TOAST_THRESHOLD and hard code it as the
>> same
>> expression that's there now. Ie, the largest size that can fit in a page.
> No
Chris Browne <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Tom Lane) writes:
>> ... tuning the TOAST parameters seems like
>> something we understand well enough already, we just need to put some
>> cycles into testing different alternatives. I would have no objection
>> to someone working on t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, are you going to do this for 8.3?
Right, I promised to do that --- will work on it now.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL p
Tom, are you going to do this for 8.3?
---
Tom Lane wrote:
> In another thread I wrote:
> > ... One thing I was just thinking about is that it's silly to have
> > the threshold constrained so strongly by a desire that tuples
[EMAIL PROTECTED] (Tom Lane) writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Well it certainly seems worth separating them. It does seem possible
>> that recursive toasting effected some of the earlier results we looked
>> at.
>
>> Would you like me to do this, or will you?
>
> I'm willing t
[EMAIL PROTECTED] (Tom Lane) wrote:
> I'm willing to do the code changes to separate TOAST_THRESHOLD from
> the toast chunk size, but I do not have the time or facilities to do
> any performance testing for different parameter choices. Anyone
> want to work on that?
What have you got in mind ther
On Thu, 2007-03-29 at 12:05 -0400, Tom Lane wrote:
> I think the WAL-reduction proposal needs more time and thought than is
> feasible before 8.3.
Agreed.
We really need to focus on the major features.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Well it certainly seems worth separating them. It does seem possible
> that recursive toasting effected some of the earlier results we looked
> at.
> Would you like me to do this, or will you?
I'm willing to do the code changes to separate TOAST_THRESHO
On Wed, 2007-03-28 at 14:08 -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
> >> compiled-in parameters that are recorded in pg_control and checked for
> >> compat
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
>> compiled-in parameters that are recorded in pg_control and checked for
>> compatibility at startup (like BLCKSZ) --- this will prevent anyone
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I also think that we ought to add TOAST_MAX_CHUNK_SIZE to the set of
> compiled-in parameters that are recorded in pg_control and checked for
> compatibility at startup (like BLCKSZ) --- this will prevent anyone from
> shooting themselves in the foot while
In another thread I wrote:
> ... One thing I was just thinking about is that it's silly to have
> the threshold constrained so strongly by a desire that tuples in toast
> tables not be toastable. It would be trivial to tweak the heapam.c
> routines so that they simply don't invoke the toaster when
31 matches
Mail list logo
