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
On Tue, Jul 2, 2013 at 11:06 AM, Andres Freund and...@2ndquadrant.com 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
On 2013-06-28 11:25:50 -0400, Robert Haas wrote:
On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com
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
On Mon, Jul 1, 2013 at 3:49 PM, Andres Freund and...@2ndquadrant.com 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
On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund and...@2ndquadrant.com 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
On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund and...@2ndquadrant.com
wrote:
Please find attached the next version of the extensible toast
support. There basically are two changes:
* handle indirect toast tuples
On 2013-06-28 09:49:53 -0400, Robert Haas wrote:
On Fri, Jun 28, 2013 at 9:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 27, 2013 at 12:56 PM, Andres Freund and...@2ndquadrant.com
wrote:
Please find attached the next version of the extensible toast
support. There basically
On Fri, Jun 28, 2013 at 10:53 AM, Andres Freund and...@2ndquadrant.com 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,
On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund and...@2ndquadrant.com 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.
On Thu, Jun 27, 2013 at 6:08 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund and...@2ndquadrant.com
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
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
On 2013-06-27 09:17:10 -0700, Hitoshi Harada wrote:
On Thu, Jun 27, 2013 at 6:08 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 19, 2013 at 3:27 AM, Andres Freund and...@2ndquadrant.com
wrote:
There will be a newer version of the patch coming today or tomorrow, so
there's
On Wed, Jun 5, 2013 at 8:01 AM, Andres Freund and...@2ndquadrant.comwrote:
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...
On 2013-06-19 00:15:56 -0700, Hitoshi Harada wrote:
On Wed, Jun 5, 2013 at 8:01 AM, Andres Freund and...@2ndquadrant.comwrote:
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
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.comwrote:
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
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.comwrote:
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
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.com
wrote:
Here's the updated version. It shouldn't contain any obvious WIP pieces
On 2013-06-18 10:13:39 -0700, Hitoshi Harada wrote:
On Tue, Jun 18, 2013 at 1:58 AM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-06-18 00:56:17 -0700, Hitoshi Harada wrote:
On Fri, Jun 14, 2013 at 4:06 PM, Andres Freund and...@2ndquadrant.com
wrote:
Here's the updated
On 2013-05-31 23:42:51 -0400, Robert Haas wrote:
On Thu, May 30, 2013 at 7:42 AM, Andres Freund and...@2ndquadrant.com 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
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-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 :/
On Wed, Jun 5, 2013 at 11:01 AM, Andres Freund and...@2ndquadrant.com 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.
On 2013-06-07 10:04:15 -0400, Robert Haas wrote:
On Wed, Jun 5, 2013 at 11:01 AM, Andres Freund and...@2ndquadrant.com 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
On Fri, Jun 7, 2013 at 10:30 AM, Andres Freund and...@2ndquadrant.com 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
On 2013-06-07 10:44:24 -0400, Robert Haas wrote:
On Fri, Jun 7, 2013 at 10:30 AM, Andres Freund and...@2ndquadrant.com 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
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 compressed but
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 'very fast but
Andres Freund and...@2ndquadrant.com 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
On 2013-06-07 11:46:45 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 Herrera
Andres Freund and...@2ndquadrant.com 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
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
sufficient
* 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 ever
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 and xx
On Thu, May 30, 2013 at 7:42 AM, Andres Freund and...@2ndquadrant.com 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
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
36 matches
Mail list logo
