Andres Freund writes:
> On 2014-04-27 18:44:16 -0400, Tom Lane wrote:
>> They don't get nearly as upset as they do if the database loses their
>> data. Yes, in an ideal world, we could fix this and not suffer any
>> performance loss anywhere. But no such option is on the table, and
>> waiting is
On 2014-04-27 18:44:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> Just for some clarity, that also happens with expressions like:
> >> WHERE
> >> ROW(ev_class, rulename, ev_action) >= ROW('pg_rewrite'::regclass,
> >> '_RETURN', NULL)
> >> ORDER BY ROW(ev_class, rulename, ev_action);
>
>
Andres Freund writes:
>> Just for some clarity, that also happens with expressions like:
>> WHERE
>> ROW(ev_class, rulename, ev_action) >= ROW('pg_rewrite'::regclass, '_RETURN',
>> NULL)
>> ORDER BY ROW(ev_class, rulename, ev_action);
> Previously we wouldn't detoast ev_action here, but now we d
On 2014-04-27 17:49:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-27 14:18:46 -0400, Tom Lane wrote:
> >> Ah, I see. Well, we're pretty darn stupid about such queries anyway :-(.
> >> Your first example could be greatly improved by expanding the whole-row
> >> Var into a ROW()
Andres Freund writes:
> On 2014-04-27 14:18:46 -0400, Tom Lane wrote:
>> Ah, I see. Well, we're pretty darn stupid about such queries anyway :-(.
>> Your first example could be greatly improved by expanding the whole-row
>> Var into a ROW() construct (so that RowCompareExpr could be used), and
>>
On 2014-04-27 14:18:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
> >>> Meh ... is it likely that the columns involved in an ordering comparison
> >>> would be so wide as to be toasted out-of-line? Such a query would only be
> >>> fast if the
Andres Freund writes:
>> On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
>>> Meh ... is it likely that the columns involved in an ordering comparison
>>> would be so wide as to be toasted out-of-line? Such a query would only be
>>> fast if the row value were indexed, which would pretty much preclud
On 2014-04-25 18:25:44 +0200, Andres Freund wrote:
> On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > The case I am worried most about is queries like:
> > > SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
> > > I've seen such generated by a some query gen
On 2014-04-25 12:05:17 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The case I am worried most about is queries like:
> > SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
> > I've seen such generated by a some query generators for paging. But I
> > guess that's something we're go
Andres Freund writes:
> The case I am worried most about is queries like:
> SELECT a, b FROM f WHERE f > ROW(38, 'whatever') ORDER BY f;
> I've seen such generated by a some query generators for paging. But I
> guess that's something we're going to have to accept.
Meh ... is it likely that the co
On 2014-04-25 11:22:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-24 19:40:30 -0400, Tom Lane wrote:
> >> * Because HeapTupleGetDatum might allocate a new tuple, the wrong thing
> >> might happen if the caller changes CurrentMemoryContext between
> >> heap_form_tuple and HeapTup
Andres Freund writes:
> On 2014-04-24 19:40:30 -0400, Tom Lane wrote:
>> * Because HeapTupleGetDatum might allocate a new tuple, the wrong thing
>> might happen if the caller changes CurrentMemoryContext between
>> heap_form_tuple and HeapTupleGetDatum.
> It's fscking ugly to allocate memory in a
Hi,
On 2014-04-24 19:40:30 -0400, Tom Lane wrote:
> * Because HeapTupleGetDatum might allocate a new tuple, the wrong thing
> might happen if the caller changes CurrentMemoryContext between
> heap_form_tuple and HeapTupleGetDatum.
It's fscking ugly to allocate memory in a PG_RETURN_... But I don'
Heikki Linnakangas writes:
> On 04/25/2014 02:40 AM, Tom Lane wrote:
>> * The patch changes HeapTupleGetDatum from a simple inline macro into
>> a function call. This means that third-party extensions will not get
>> protection against creation of toast-pointer-containing composite Datums
>> unti
On 04/25/2014 02:40 AM, Tom Lane wrote:
* The patch changes HeapTupleGetDatum from a simple inline macro into
a function call. This means that third-party extensions will not get
protection against creation of toast-pointer-containing composite Datums
until they recompile.
One consequence of t
I wrote:
> I'm actually planning to set this patch on the shelf for a bit and go
> investigate the other alternative, ie, not generating composite Datums
> containing toast pointers in the first place.
Here's a draft patch along those lines. It turned out to be best to
leave heap_form_tuple() alo
Noah Misch writes:
> On Mon, Apr 21, 2014 at 10:57:34AM -0400, Tom Lane wrote:
>> I'm actually planning to set this patch on the shelf for a bit and go
>> investigate the other alternative, ie, not generating composite Datums
>> containing toast pointers in the first place.
> I maintain that the
On Mon, Apr 21, 2014 at 10:57:34AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I wonder how it would work out to instead delay this new detoast effort
> > until
> > toast_insert_or_update().
>
> That would require toast_insert_or_update() to know about every container
> datatype. I doubt it
Merlin Moncure wrote:
> On Mon, Apr 21, 2014 at 10:40 AM, Andres Freund
> wrote:
> > And too bad that infomask bits are so scarce :(. We really need to
> > reclaim HEAP_MOVED_OFF and HEAP_MOVED_IN.
>
> The only consequence of that is losing support for in-place update for
> pre-9.0 (of which th
On Mon, Apr 21, 2014 at 10:40 AM, Andres Freund wrote:
> On 2014-04-21 11:30:57 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > I unfortunately haven't followed this in detail, but shouldn't it be
>> > relatively easily to make this even cheaper by checking for
>> > HEAP_HASEXTERNAL? If it'
On 2014-04-21 11:30:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I unfortunately haven't followed this in detail, but shouldn't it be
> > relatively easily to make this even cheaper by checking for
> > HEAP_HASEXTERNAL? If it's not set we don't need to iterate over the
> > composite's co
Andres Freund writes:
> I unfortunately haven't followed this in detail, but shouldn't it be
> relatively easily to make this even cheaper by checking for
> HEAP_HASEXTERNAL? If it's not set we don't need to iterate over the
> composite's columns, right?
That's the point I made further down: we
Hi,
On 2014-04-20 15:38:23 -0400, Tom Lane wrote:
> Some poking around with oprofile says that much of the added time is
> coming from added syscache and typcache lookups, as I suspected.
>
> I did some further work on the patch to make it possible to cache
> the element tuple descriptor across c
Noah Misch writes:
> I wonder how it would work out to instead delay this new detoast effort until
> toast_insert_or_update().
That would require toast_insert_or_update() to know about every container
datatype. I doubt it could lead to an extensible or maintainable
solution.
I'm actually planni
I lack time to give this a solid review, but here's a preliminary reaction:
On Sun, Apr 20, 2014 at 03:38:23PM -0400, Tom Lane wrote:
> On HEAD, this takes about 295-300 msec on my machine in a non-cassert
> build. With the patch I sent previously, the time goes to 495-500 msec.
> This goes from
I wrote:
> The main problem with this patch, as I see it, is that it'll introduce
> extra syscache lookup overhead even when there are no toasted fields
> anywhere. I've not really tried to quantify how much, since that would
> require first agreeing on a benchmark case --- anybody have a thought
Noah Misch writes:
> Interesting bug.
> On Fri, Mar 28, 2014 at 04:34:41PM -0400, Tom Lane wrote:
>> I think we might be better off to get rid of toast_flatten_tuple_attribute
>> and instead insist that composite Datums never contain any external toast
>> pointers in the first place.
> Performanc
Interesting bug.
On Fri, Mar 28, 2014 at 04:34:41PM -0400, Tom Lane wrote:
> I think we might be better off to get rid of toast_flatten_tuple_attribute
> and instead insist that composite Datums never contain any external toast
> pointers in the first place. That is, places that call heap_form_tu
Merlin Moncure writes:
> Trying to follow along here. Am I correct in saying that if you make
> these changes any SQL level functionality (say, creating a composite
> type containing a large array) that used to work will continue to
> work?
This wouldn't change any SQL-level functionality ... as
On Fri, Mar 28, 2014 at 3:34 PM, Tom Lane wrote:
> Way way back in commit ae93e5fd6e8a7e2321e87d23165d9d7660cde598,
> we established a coding rule that it was okay for composite Datums
> to contain external (out-of-line) toasted fields, as long as such
> toasting didn't go more than one level deep
Way way back in commit ae93e5fd6e8a7e2321e87d23165d9d7660cde598,
we established a coding rule that it was okay for composite Datums
to contain external (out-of-line) toasted fields, as long as such
toasting didn't go more than one level deep in any tuple. This meant
that heap_form_tuple had to go
31 matches
Mail list logo
