Jeff Davis <[EMAIL PROTECTED]> writes:
> On Sun, 2008-06-29 at 16:57 -0400, Tom Lane wrote:
>> After playing with it for a little bit, I'm not convinced that it buys
>> enough performance win to be worth applying --- the restriction of cache
>> lifespan to one tuple cycle of a TupleTableSlot is awf
On Sun, 2008-06-29 at 16:57 -0400, Tom Lane wrote:
> After playing with it for a little bit, I'm not convinced that it buys
> enough performance win to be worth applying --- the restriction of cache
> lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive.
> (For example, sorts that
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
> Eliminate de-TOASTing of values when not needed
That's a fairly bad description of what the patch was about. I changed
it to
Reduce costs of repeat de-TOASTing of values
regards, tom lane
--
Sen
Added to TODO:
Eliminate de-TOASTing of values when not needed
---
Tom Lane wrote:
> Attached is a worked-out patch for the approach proposed here:
> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00777.php
Gregory Stark wrote:
> Well at least it caught the bug that Mark was performance testing with a
> --enable-cassert build :/
True ;) I appreciated that there would be some overhead, but I didn't
think it would be that much. This was mainly since I seem to remember
there was talk a while back o
>> I'm inclined to think that we'd better turn that off by default,
>> since it's not looking like it's catching anything new.
Well at least it caught the bug that Mark was performance testing with a
--enable-cassert build :/
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.c
Tom Lane wrote:
> OK, I've reproduced the test case locally. I believe that when you
> say "worse", you mean "worse than 8.3", right? And you did tell me
> offlist that you were testing with --enable-cassert. CVS HEAD has
> very substantially greater cassert overhead because of the
> randomize
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It would be simple enough to fix nodeSubplan.c to copy the data into
>> an upper-level Slot rather than a bare tuple. But this makes me wonder
>> how many other places are like this. In the past there wasn't that much
>> benefit to p
Tom Lane wrote:
> It would be simple enough to fix nodeSubplan.c to copy the data into
> an upper-level Slot rather than a bare tuple. But this makes me wonder
> how many other places are like this. In the past there wasn't that much
> benefit to pulling data from a Slot instead of a bare tuple,
[ back on-list ]
Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> Thanks very much for supplying the WIP patch. In the interest of testing
> and feedback, I've just downloaded PostgreSQL CVS head and applied your
> patch, compiled up a slightly modified version of PostGIS (without
> RECHECKs on t
Mark Cave-Ayland <[EMAIL PROTECTED]> writes:
> Unfortunately I have to report back that with your WIP patch applied,
> timings seem to have become several orders of magnitude *worse*:
Ugh. Could I pester you to run the case under gprof or oprofile?
Or, if you can give me step-by-step directions
Guillaume Smet wrote:
From the discussion we had a few months ago, I don't think the no
RECHECK trick works with CVS tip anymore.
See my post on the "Remove lossy-operator RECHECK flag?" thread:
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00847.php
and follow-ups.
That said, perhap
Mark,
On Tue, Jul 1, 2008 at 1:15 PM, Mark Cave-Ayland
<[EMAIL PROTECTED]> wrote:
> Thanks very much for supplying the WIP patch. In the interest of testing and
> feedback, I've just downloaded PostgreSQL CVS head and applied your patch,
> compiled up a slightly modified version of PostGIS (withou
Tom Lane wrote:
Attached is a worked-out patch for the approach proposed here:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00777.php
namely, that cache management for de-TOASTed datums is handled
by TupleTableSlots.
To avoid premature detoasting of values that we might never need, th
"Tom Lane" <[EMAIL PROTECTED]> writes:
> After playing with it for a little bit, I'm not convinced that it buys
> enough performance win to be worth applying --- the restriction of cache
> lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive.
> (For example, sorts that involve to
Attached is a worked-out patch for the approach proposed here:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00777.php
namely, that cache management for de-TOASTed datums is handled
by TupleTableSlots.
To avoid premature detoasting of values that we might never need, the
patch introduces
16 matches
Mail list logo
