[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
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 big win
[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 the threshold to
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 performance
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
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 alternatives. I
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
cycles into testing
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 decisions
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 variable, which
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 extremely good reason not to
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 before it's
[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
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:
Well it
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 looked
at.)
... 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 had
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 that it
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 my
[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 to do the code
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 in
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
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 that during
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, right now
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 had
[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 have no
[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 there?
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
compatibility at
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_THRESHOLD from
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
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
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
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 from
31 matches
Mail list logo
