On Mon, Feb 7, 2011 at 11:52 PM, Noah Misch n...@leadboat.com wrote:
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:
!var-isnull var-datatype-typbyval var-datatype-typlen ==
On Tue, Feb 08, 2011 at 08:00:42AM +0100, Pavel Stehule wrote:
2011/2/8 Noah Misch n...@leadboat.com:
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:
!var-isnull
2011/2/8 Noah Misch n...@leadboat.com:
On Tue, Feb 08, 2011 at 08:00:42AM +0100, Pavel Stehule wrote:
2011/2/8 Noah Misch n...@leadboat.com:
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its
2011/2/8 Robert Haas robertmh...@gmail.com:
On Mon, Feb 7, 2011 at 11:52 PM, Noah Misch n...@leadboat.com wrote:
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:
!var-isnull
On Tue, Feb 08, 2011 at 10:24:03AM -0500, Robert Haas wrote:
Well, Pavel's subsequent reply suggested that he didn't test exactly
this thing, so maybe there's hope.
No hope on that basis, no.
Or maybe not. If Tom thought one branch inside exec_eval_datum() was
going to be too expensive,
2011/2/8 Noah Misch n...@leadboat.com:
On Tue, Feb 08, 2011 at 10:24:03AM -0500, Robert Haas wrote:
Well, Pavel's subsequent reply suggested that he didn't test exactly
this thing, so maybe there's hope.
No hope on that basis, no.
Or maybe not. If Tom thought one branch inside
On Tue, Feb 8, 2011 at 11:38 AM, Noah Misch n...@leadboat.com wrote:
It's not as if this patch raised complex questions that folks need more time
to
digest. For a patch this small and simple, we minimally owe Pavel a direct
answer about its rejection.
Well, I don't see how we can give a
On Sun, Feb 6, 2011 at 9:10 AM, Robert Haas robertmh...@gmail.com wrote:
Suppose foo is toasted. As the code stands in master, it gets detoasted in
text_lt(). Certainly we won't overwrite the source back in PL/pgSQL from the
detoast point in text_lt().
Right, that much seems obvious...
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:
!var-isnull var-datatype-typbyval var-datatype-typlen == -1
VARATT_IS_EXTENDED(var-value)
FWIW, this is what I meant by
2011/2/8 Robert Haas robertmh...@gmail.com:
On Sun, Feb 6, 2011 at 9:10 AM, Robert Haas robertmh...@gmail.com wrote:
Suppose foo is toasted. As the code stands in master, it gets detoasted
in
text_lt(). Certainly we won't overwrite the source back in PL/pgSQL from
the
detoast point in
2011/2/8 Noah Misch n...@leadboat.com:
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:
!var-isnull var-datatype-typbyval var-datatype-typlen == -1
Let's see if I can summarize the facts we've collected so far. I see four
options based on the discussion:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
Essentially Pavel's original patch, only with the check logic moved up from
exec_eval_datum() to
On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch n...@leadboat.com wrote:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
Essentially Pavel's original patch, only with the check logic moved up from
exec_eval_datum() to plpgsql_param_fetch() to avoid bothering a couple other
On Sun, Feb 06, 2011 at 08:15:30AM -0500, Robert Haas wrote:
On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch n...@leadboat.com wrote:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
Essentially Pavel's original patch, only with the check logic moved up from
On Sun, Feb 6, 2011 at 8:47 AM, Noah Misch n...@leadboat.com wrote:
On Sun, Feb 06, 2011 at 08:15:30AM -0500, Robert Haas wrote:
On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch n...@leadboat.com wrote:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
Essentially Pavel's
On Fri, Jan 28, 2011 at 2:19 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2011/1/28 Robert Haas robertmh...@gmail.com:
On Tue, Jan 25, 2011 at 11:29 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
variant a) my first patch - detoast on first usage with avoiding to
useless detoast
2011/2/4 Robert Haas robertmh...@gmail.com:
On Fri, Jan 28, 2011 at 2:19 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
2011/1/28 Robert Haas robertmh...@gmail.com:
On Tue, Jan 25, 2011 at 11:29 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
variant a) my first patch - detoast on first
On Tue, Jan 25, 2011 at 11:29 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
variant a) my first patch - detoast on first usage with avoiding to
useless detoast checking
variant b) my first patch - detoast on first usage without avoiding to
useless detoast checking
time for 1 - about 300
2011/1/28 Robert Haas robertmh...@gmail.com:
On Tue, Jan 25, 2011 at 11:29 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
variant a) my first patch - detoast on first usage with avoiding to
useless detoast checking
variant b) my first patch - detoast on first usage without avoiding to
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Detoasting on first usage, ie. exec_eval_datum(), seems the best to me.
Compared to detoasting on assignment, it avoids the performance
regression if the value is never used, and I don't think checking if the
value is toasted at
On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Detoasting on first usage, ie. exec_eval_datum(), seems the best to me.
Compared to detoasting on assignment, it avoids the performance
regression if the value is
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The arguments that were made against this were about maintenance costs
and code footprint. Claims about performance are not really relevant,
especially when they're entirely
On Tue, Jan 25, 2011 at 10:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The arguments that were made against this were about maintenance costs
and code footprint. Claims about
2011/1/25 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The arguments that were made against this were about maintenance costs
and code footprint. Claims about performance are not really relevant,
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameters.
I can confirm that, for your original test case, this yields
Hello
2011/1/25 Noah Misch n...@leadboat.com:
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameters.
I can
On 25.01.2011 06:29, Pavel Stehule wrote:
2011/1/25 Noah Mischn...@leadboat.com:
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast
Hello,
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameters.
Regards
Pavel
2011/1/19 Robert Haas robertmh...@gmail.com:
On Wed, Jan 19, 2011 at 4:18 PM, Tom Lane
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost use cases (problem is thousands
detoasting).
Yeah. Many-times-repeated detoasting is really bad, and this is
2011/1/19 Robert Haas robertmh...@gmail.com:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost use cases (problem is thousands
detoasting).
Yeah.
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost use cases (problem is thousands
detoasting).
Yeah.
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost
On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost use
Noah Misch n...@leadboat.com writes:
On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote:
In the meantime, the proposal at hand seems like a bit of a stop-gap,
which is why I'd prefer to see something with a very minimal code
footprint. Detoast at assignment would likely need only a few
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. Many-times-repeated detoasting is really bad, and this is not
the only place in the backend where we have this problem. :-(
Yeah,
On Wed, Jan 19, 2011 at 2:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 19, 2011 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. Many-times-repeated detoasting is really bad, and this is not
the
Robert Haas robertmh...@gmail.com writes:
I do remember that discussion. Aside from the problem you mention, it
also seems that maintaining the hash table and doing lookups into it
would have some intrinsic cost.
Well, sure, but it's still far cheaper than going out to the toast table
(which
Tom Lane t...@sss.pgh.pa.us wrote:
If we could solve the refcounting problem I think this would be a
very significant win.
Instead of trying to keep a refcount, how about just evicting from
the buffer as needed based on LRU?
-Kevin
--
Sent via pgsql-hackers mailing list
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
If we could solve the refcounting problem I think this would be a
very significant win.
Instead of trying to keep a refcount, how about just evicting from
the buffer as needed based on LRU?
Well, unless
On Wed, Jan 19, 2011 at 4:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One idea that I think we discussed was to tie cache entries to the
memory context they were demanded in, and mark them unused at the next
context reset/delete. That way they'd be considered unused at the same
points where the
Noah Misch n...@leadboat.com writes:
On Sun, Jan 16, 2011 at 06:49:27PM +0100, Pavel Stehule wrote:
I am sending a updated version with little bit more comments. But I am
sure, so somebody with good English have to edit my comments.
Minimally I hope, so your questions will be answered.
2011/1/18 Tom Lane t...@sss.pgh.pa.us:
Noah Misch n...@leadboat.com writes:
On Sun, Jan 16, 2011 at 06:49:27PM +0100, Pavel Stehule wrote:
I am sending a updated version with little bit more comments. But I am
sure, so somebody with good English have to edit my comments.
Minimally I hope, so
Pavel Stehule pavel.steh...@gmail.com writes:
2011/1/18 Tom Lane t...@sss.pgh.pa.us:
I looked at this patch and found it fairly awkward. Â What is the point
of adding an additional flag to every variable, as opposed to just
forcibly detoasting during assignment?
But detoasting on assignment
2011/1/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2011/1/18 Tom Lane t...@sss.pgh.pa.us:
I looked at this patch and found it fairly awkward. What is the point
of adding an additional flag to every variable, as opposed to just
forcibly detoasting during
Hello
2011/1/15 Noah Misch n...@leadboat.com:
Hello Pavel,
I'm reviewing this patch for CommitFest 2011-01.
Thank you very much,
I am sending a updated version with little bit more comments. But I am
sure, so somebody with good English have to edit my comments.
Minimally I hope, so your
On Sun, Jan 16, 2011 at 06:49:27PM +0100, Pavel Stehule wrote:
I am sending a updated version with little bit more comments. But I am
sure, so somebody with good English have to edit my comments.
Minimally I hope, so your questions will be answered.
Thanks. I edited the comments and white
Hello Pavel,
I'm reviewing this patch for CommitFest 2011-01.
The patch seems fully desirable. It appropriately contains no documentation
updates. It contains no new tests, and that's probably fine, too; I can't think
of any corner cases where this would do something other than work correctly
47 matches
Mail list logo
