elein <[EMAIL PROTECTED]> writes:
> I want to register, just in principle, that I object to changing
> the structure of a varlena.
Indeed, I'm doing my best to restrain Greg from changing what a
datatype-specific function will see by default. The stuff with
variable-length headers should be con
I want to register, just in principle, that I object to changing
the structure of a varlena.
The idea behind the data type is simple, clean and fast. And it is
easily understood by developers and by people developing applications
and functions in PostgreSQL.
Of course you will do what you wi
On Tue, Feb 13, 2007 at 01:32:11PM -0500, Bruce Momjian wrote:
> Gregory Stark wrote:
> > Alternatively, what does the trailing "a" in varlena signify? Would this be
> > varlenb?
>
> "attribute"
>
> --
Actually varlena stands for "variable length array."
elein
[EMAIL PROTECTED]
--
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Any such site is already broken, because with the proposed design, code
>> is only exposed to short-header datums if it is also exposed to toasted
>> datums.
> Well the toaster doesn't run until we were about t
Gregory Stark wrote:
> Alternatively, what does the trailing "a" in varlena signify? Would this be
> varlenb?
"attribute"
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive,
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> You keep suggesting things that I've previously considered and rejected --
>> perhaps prematurely. Off the top of my head I recall the following four
>> options from our discussions. It looks like we're circling
Tom Lane wrote:
> > We detect cases where the typmod guarantees either a fixed size or a maximum
> > size < 256 bytes.
>
> After last week I would veto this option anyway: it fails unless we
> always know typmod exactly, and I'm here to tell you we don't.
If we can pull this off, it handles short
Gregory Stark <[EMAIL PROTECTED]> writes:
> You keep suggesting things that I've previously considered and rejected --
> perhaps prematurely. Off the top of my head I recall the following four
> options from our discussions. It looks like we're circling around option 4.
No, I think I'm arguing for
Hey all:
This is a randomly inserted distraction to tell you that I really like to
read about these ideas. No input from myself at this point. I'm happy with
the direction you are taking.
Thanks,
mark
--
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> Uh, if the macros can read 1 and 4-byte headers, why do we need to
>> allocate memory for them?
> Because the macros can't read 1 and 4-byte headers. If they could we would
> have the problem with VARDATA fo
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The point I'm trying to get across here is to do things one small step
> at a time; if you insist on a "big bang" patch then it'll never get
> done. You might want to go back and review the CVS history for some
> other big changes like TOAST and the versi
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> >> But I'm surprised, I had the impression that you were reluctant to consider
> >> memcpying all the data all the time.
> >
> > Uh, if the macros can read 1 and 4-byte headers, why do we need to
> > allocate memory for them
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> But I'm surprised, I had the impression that you were reluctant to consider
>> memcpying all the data all the time.
>
> Uh, if the macros can read 1 and 4-byte headers, why do we need to
> allocate memory for them?
Because the macros can't read 1 an
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I'd be inclined to put the intelligence into heap_form_tuple and thereby
>> avoid getting the TOAST code involved unless there are wide fields to
>> deal with.
> And have heap_deform_tuple / heap_getattr palloc and me
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > > So (nigh) every tuple will get deformed and reformed once before it goes
> > > to
> > > disk? Currently the toast code doesn't even look at a tuple if it's small
> > > enough, but in this case we would want it to fire even on very n
Tom Lane <[EMAIL PROTECTED]> writes:
> > So (nigh) every tuple will get deformed and reformed once before it goes to
> > disk? Currently the toast code doesn't even look at a tuple if it's small
> > enough, but in this case we would want it to fire even on very narrow rows.
>
> I'd be inclined to
Gregory Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > I don't really see a way around it though. Places that fill in VARDATA
> > > before
> > > the size (formatting.c seems to be the worst case) will just have to be
> > > changed and
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> (1) code written to existing practice will always generate 4-byte
>> headers. (Hence, VARDATA() acts the same as now.) That's the format
>> that generally gets passed around in memory.
> So then we don't need to
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > I don't really see a way around it though. Places that fill in VARDATA
> > before
> > the size (formatting.c seems to be the worst case) will just have to be
> > changed and it'll be a fairly fragile point.
>
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> But if you are walking through attributes, how do you know to look at
> the next byte or the next aligned byte? We have to force zeros in
> there?
Yup: pad bytes must be zeroes (they are already) and a 1-byte-header
can't be a zero (easily done if its l
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Heikki Linnakangas wrote:
> >> We would still require all datums with a 4-byte header to be 4-byte
> >> aligned, right? When reading, you would first check if it's a compressed
> >> or uncompressed header. If compressed, read the 1 byte header,
Bruce Momjian wrote:
Heikki Linnakangas wrote:
We would still require all datums with a 4-byte header to be 4-byte
aligned, right? When reading, you would first check if it's a compressed
or uncompressed header. If compressed, read the 1 byte header, if
uncompressed, read the 4-byte header and
Heikki Linnakangas wrote:
> Gregory Stark wrote:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> For example it'd be easy to implement the previously-discussed design
> >> involving storing uncompressed length words in network byte order:
> >> SET_VARLENA_LEN does htonl() and VARSIZE does ntohl() a
Gregory Stark <[EMAIL PROTECTED]> writes:
> I don't really see a way around it though. Places that fill in VARDATA before
> the size (formatting.c seems to be the worst case) will just have to be
> changed and it'll be a fairly fragile point.
No, we're not going there: it'd break too much code now
On Tue, Feb 13, 2007 at 09:44:03AM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> Could the "new style" macros be back-ported to previous releases in case
> >> we do this?
>
> > Yes, Tom and I talked about this. It could appear in the next minor
Gregory Stark wrote:
> a) To have two sets of macros, one of which, VARATT_DATA and
> VARATT_SIZEP are for constructing new tuples and behaves exactly as
> it does now. So you always construct a four-byte header datum. Then
> in heap_form*tuple we check if you can use a shorter header and
> convert
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> Could the "new style" macros be back-ported to previous releases in case
>> we do this?
> Yes, Tom and I talked about this. It could appear in the next minor
> release of all branches.
I don't really see the point of that. Th
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
>> Actually I think neither htonl nor bitshifting the entire 4-byte word is
>> going
>> to really work here. Both will require 4-byte alignment. Instead I think we
>> have to access the length byte by byte as a (char*) and do arithmetic. Since
>> i
Gregory Stark wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
For example it'd be easy to implement the previously-discussed design
involving storing uncompressed length words in network byte order:
SET_VARLENA_LEN does htonl() and VARSIZE does ntohl() and nothing else in
the per-datatype function
Magnus Hagander wrote:
> On Mon, Feb 12, 2007 at 11:19:14PM -0500, Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
>
> > By my count there are only 170 uses of VARATT_SIZEP in the entire
> > backend (including contrib) so this is not an especially daunting
> > change. It would break
"Tom Lane" <[EMAIL PROTECTED]> writes:
> If we replaced that line with something like
>
> SET_VARLENA_LEN(result, len + VARHDRSZ);
>
> then we'd have a *whole* lot more control.
I think that part was already clear. The problem was in VARDATA.
I don't really see a way around it though. P
On Mon, Feb 12, 2007 at 11:19:14PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> By my count there are only 170 uses of VARATT_SIZEP in the entire
> backend (including contrib) so this is not an especially daunting
> change. It would break existing user-written functions th
Gregory Stark <[EMAIL PROTECTED]> writes:
> Do you see any way to avoid having every user function everywhere
> use a new macro api instead of VARDATA/VARATT_DATA and VARSIZE/VARATT_SIZEP?
Bruce and I had a long phone conversation about that today. We
concluded that there doesn't seem to be any s
I've been looking at this again and had a few conversations about it. This may
be easier than I had originally thought but there's one major issue that's
bugging me. Do you see any way to avoid having every user function everywhere
use a new macro api instead of VARDATA/VARATT_DATA and VARSIZE/VAR
Bruce Momjian wrote:
> Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > That seems like an awful lot of copying and pallocs that aren't there
> > > currently though. And it'll make us reluctant to change over frequently
> > > used
> > > data types like text -- which are precisel
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > That seems like an awful lot of copying and pallocs that aren't there
> > currently though. And it'll make us reluctant to change over frequently used
> > data types like text -- which are precisely the ones that would gain us the
> >
Gregory Stark <[EMAIL PROTECTED]> writes:
> That seems like an awful lot of copying and pallocs that aren't there
> currently though. And it'll make us reluctant to change over frequently used
> data types like text -- which are precisely the ones that would gain us the
> most.
> It seems to me th
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> Uh. So I don't see how to make this work on a little-endian machine. If the
>> leading its are 0 we don't know if they're toast flags or bits on the least
>> significant byte of a longer length.
>> ...
> I had forgotten about hooking into the TOAST s
Greg Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >> I know it is kind of odd to have a data type that is only used on disk,
> > >> and not in memory, but I see this as a baby varlena type, used
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> I know it is kind of odd to have a data type that is only used on disk,
> >> and not in memory, but I see this as a baby varlena type, used only to
> >> store and get va
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> I know it is kind of odd to have a data type that is only used on disk,
>>> and not in memory, but I see this as a baby varlena type, used only to
>>> store and get varl
Greg Stark <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I know it is kind of odd to have a data type that is only used on disk,
>> and not in memory, but I see this as a baby varlena type, used only to
>> store and get varlena values using less disk space.
> I was lea
Greg Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Bruce Momjian wrote:
> > >
> > > Uh, I thought the approach was to create type-specific in/out functions,
> > > and add casting so every time there were referenced, they would expand
> > > to a varlena structure in memory.
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
> >
> > Uh, I thought the approach was to create type-specific in/out functions,
> > and add casting so every time there were referenced, they would expand
> > to a varlena structure in memory.
Are you talking about actual casts?
Bruce Momjian wrote:
>
> Uh, I thought the approach was to create type-specific in/out functions,
> and add casting so every time there were referenced, they would expand
> to a varlena structure in memory.
Oh, one more thing. You are going to need to teach the code that walks
through a tuple at
Uh, I thought the approach was to create type-specific in/out functions,
and add casting so every time there were referenced, they would expand
to a varlena structure in memory.
---
Gregory Stark wrote:
>
> I've been lookin
46 matches
Mail list logo
