On Tue, Jul 2, 2013 at 11:06 AM, Andres Freund wrote:
> In that case the old value will rather likely just have been read just
> before, so the price of rereading should be relatively low.
Maybe in terms of I/O, but there's still CPU.
> is a rather valid point. I've split the patch accordingly.
On 2013-07-01 17:46:51 -0400, Robert Haas wrote:
> But backing up a minute, this is really a significant behavior change
> that is independent of the purpose of the rest of this patch. What
> you're proposing here is that every time we consider toasting a value
> on update, we should first check w
On Mon, Jul 1, 2013 at 3:49 PM, Andres Freund wrote:
>> I must be missing something. At that point, yes, you'd like to avoid
>> re-toasting unnecessarily, but ISTM you've already bought the farm.
>> Unless I'm misunderstanding the code as written, you'd just end up
>> writing the indirect pointer
On 2013-06-28 11:25:50 -0400, Robert Haas wrote:
> On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund
> wrote:
> >> Why does toast_insert_or_update() need to go through all the
> >> rigamarole in toast_datum_differs()? I would have thought that it
> >> could simply treat any external-indirect value
On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund wrote:
>> Why does toast_insert_or_update() need to go through all the
>> rigamarole in toast_datum_differs()? I would have thought that it
>> could simply treat any external-indirect value as needing to be
>> detoasted and retoasted, since the dest
On 2013-06-28 09:49:53 -0400, Robert Haas wrote:
> On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas wrote:
> > On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund
> > wrote:
> >> Please find attached the next version of the extensible toast
> >> support. There basically are two changes:
> >>
> >> * hand
On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas wrote:
> On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund
> wrote:
>> Please find attached the next version of the extensible toast
>> support. There basically are two changes:
>>
>> * handle indirect toast tuples properly in heap_tuple_fetch_attr
>>
On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund wrote:
> Please find attached the next version of the extensible toast
> support. There basically are two changes:
>
> * handle indirect toast tuples properly in heap_tuple_fetch_attr
> and related places
> * minor comment adjustments
It looks to
On 2013-06-27 09:17:10 -0700, Hitoshi Harada wrote:
> On Thu, Jun 27, 2013 at 6:08 AM, Robert Haas wrote:
>
> > On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund
> > wrote:
> > > There will be a newer version of the patch coming today or tomorrow, so
> > > there's probably no point in looking at th
Hi,
Please find attached the next version of the extensible toast
support. There basically are two changes:
* handle indirect toast tuples properly in heap_tuple_fetch_attr
and related places
* minor comment adjustments
Greetings,
Andres Freund
--
Andres Freund http://w
On Thu, Jun 27, 2013 at 6:08 AM, Robert Haas wrote:
> On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund
> wrote:
> > There will be a newer version of the patch coming today or tomorrow, so
> > there's probably no point in looking at the one linked above before
> > that...
>
> This patch is marked a
On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund wrote:
> There will be a newer version of the patch coming today or tomorrow, so
> there's probably no point in looking at the one linked above before
> that...
This patch is marked as "Ready for Committer" in the CommitFest app.
But it is not clear
On 2013-06-19 00:15:56 -0700, Hitoshi Harada wrote:
> On Wed, Jun 5, 2013 at 8:01 AM, Andres Freund wrote:
> >
> > Two patches attached:
> > 1) add snappy to src/common. The integration needs some more work.
> > 2) Combined patch that adds indirect tuple and snappy compression. Those
> > coul be se
On Wed, Jun 5, 2013 at 8:01 AM, Andres Freund wrote:
>
> Two patches attached:
> 1) add snappy to src/common. The integration needs some more work.
> 2) Combined patch that adds indirect tuple and snappy compression. Those
> coul be separated, but this is an experiment so far...
>
>
>
I took a look
On 2013-06-18 10:13:39 -0700, Hitoshi Harada wrote:
> On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund wrote:
>
> > On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> > > On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund > >wrote:
> > >
> > > >
> > > > Here's the updated version. It shouldn't conta
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund wrote:
> On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> > On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund >wrote:
> >
> > >
> > > Here's the updated version. It shouldn't contain any obvious WIP pieces
> > > anymore, although I think it needs s
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
> On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund wrote:
>
> >
> > Here's the updated version. It shouldn't contain any obvious WIP pieces
> > anymore, although I think it needs some more documentation. I am just
> > not sure where to add it yet,
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund wrote:
>
> Here's the updated version. It shouldn't contain any obvious WIP pieces
> anymore, although I think it needs some more documentation. I am just
> not sure where to add it yet, postgres.h seems like a bad place :/
>
>
I have a few comments a
On 2013-06-14 19:14:15 -0400, Alvaro Herrera wrote:
> Andres Freund escribió:
>
> > Here's the updated version. It shouldn't contain any obvious WIP pieces
> > anymore, although I think it needs some more documentation. I am just
> > not sure where to add it yet, postgres.h seems like a bad place
Andres Freund escribió:
> Here's the updated version. It shouldn't contain any obvious WIP pieces
> anymore, although I think it needs some more documentation. I am just
> not sure where to add it yet, postgres.h seems like a bad place :/
How about a new file, say src/include/access/toast.h?
--
On 2013-05-31 23:42:51 -0400, Robert Haas wrote:
> On Thu, May 30, 2013 at 7:42 AM, Andres Freund wrote:
> > In
> > http://archives.postgresql.org/message-id/20130216164231.GA15069%40awork2.anarazel.de
> > I presented the need for 'indirect' toast tuples which point into memory
> > instead of a to
On 2013-06-07 12:16:48 -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > Currently on a little endian system the pglz header contains the length
> > in the first four bytes as:
> > [][][][xxdd]
> > Where dd are valid length bits for pglz a
* Andres Freund (and...@2ndquadrant.com) wrote:
> Currently on a little endian system the pglz header contains the length
> in the first four bytes as:
> [][][][xxdd]
> Where dd are valid length bits for pglz and xx are the two bits which
> are always zero since we only
On 06/07/2013 05:38 PM, Andres Freund wrote:
> On 2013-06-07 17:27:28 +0200, Hannu Krosing wrote:
>> On 06/07/2013 04:54 PM, Andres Freund wrote:
>>> I mean, we don't necessarily need to make it configurable if we just add
>>> one canonical new "better" compression format. I am not sure that's
>>>
Andres Freund writes:
> On 2013-06-07 11:46:45 -0400, Tom Lane wrote:
>> IME, once we've changed it once, the odds that we'll want to change it
>> again go up drastically. I think if we're going to make a change here
>> we should leave room for future revisions.
> The above bit was just about ho
Andres Freund escribió:
> 2) Combined patch that adds indirect tuple and snappy compression. Those
> coul be separated, but this is an experiment so far...
Can we have a separate header for toast definitions? (i.e. split them
out of postgres.h)
--
Álvaro Herrerahttp://www.2ndQua
On 2013-06-07 11:46:45 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I mean, we don't necessarily need to make it configurable if we just add
> > one canonical new "better" compression format. I am not sure that's
> > sufficient since I can see usecases for 'very fast but not too well
> > com
Andres Freund writes:
> I mean, we don't necessarily need to make it configurable if we just add
> one canonical new "better" compression format. I am not sure that's
> sufficient since I can see usecases for 'very fast but not too well
> compressed' and 'very well compressed but slow', but I am p
On 2013-06-07 17:27:28 +0200, Hannu Krosing wrote:
> On 06/07/2013 04:54 PM, Andres Freund wrote:
> >
> > I mean, we don't necessarily need to make it configurable if we just add
> > one canonical new "better" compression format. I am not sure that's
> > sufficient since I can see usecases for 'ver
On 06/07/2013 04:54 PM, Andres Freund wrote:
>
> I mean, we don't necessarily need to make it configurable if we just add
> one canonical new "better" compression format. I am not sure that's
> sufficient since I can see usecases for 'very fast but not too well
> compressed' and 'very well compress
On 2013-06-07 10:44:24 -0400, Robert Haas wrote:
> On Fri, Jun 7, 2013 at 10:30 AM, Andres Freund wrote:
> > Turns out the benefits are imo big enough to make it worth pursuing
> > further.
>
> Yeah, those were nifty numbers.
>
> > The problem is that to discern from pglz on little endian the by
On Fri, Jun 7, 2013 at 10:30 AM, Andres Freund wrote:
> Turns out the benefits are imo big enough to make it worth pursuing
> further.
Yeah, those were nifty numbers.
> The problem is that to discern from pglz on little endian the byte with
> the two high bits unset is actually the fourth byte i
On 2013-06-07 10:04:15 -0400, Robert Haas wrote:
> On Wed, Jun 5, 2013 at 11:01 AM, Andres Freund wrote:
> > On 2013-05-31 23:42:51 -0400, Robert Haas wrote:
> >> > This should allow for fairly easy development of a new compression
> >> > scheme for out-of-line toast tuples. It will *not* work for
On Wed, Jun 5, 2013 at 11:01 AM, Andres Freund wrote:
> On 2013-05-31 23:42:51 -0400, Robert Haas wrote:
>> > This should allow for fairly easy development of a new compression
>> > scheme for out-of-line toast tuples. It will *not* work for compressed
>> > inline tuples (i.e. VARATT_4B_C). I am n
On Thu, May 30, 2013 at 7:42 AM, Andres Freund wrote:
> In
> http://archives.postgresql.org/message-id/20130216164231.GA15069%40awork2.anarazel.de
> I presented the need for 'indirect' toast tuples which point into memory
> instead of a toast table. In the comments to that proposal, off-list and
>
Hi,
In
http://archives.postgresql.org/message-id/20130216164231.GA15069%40awork2.anarazel.de
I presented the need for 'indirect' toast tuples which point into memory
instead of a toast table. In the comments to that proposal, off-list and
in-person talks the wish to make that a more general concep
36 matches
Mail list logo
