Added to TODO:
* Cache last known per-tuple offsets to speed long tuple access
---
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> >> i.e. for tuple with 100 cols, allocate an array of 100 pointers, p
Dann Corbit kirjutas N, 23.01.2003 kell 02:22:
> [snip]
> > So (for instance) if you have 12 variable fields, you would
> > store 12 integers at the start of the record.
>
> Additionally, you could implicitly size the integers from the properties
> of the column. A varchar(255) would only need a
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> Does this mean, that constructing tables where fixed length fields are
> 'before' variable lenght fields and 'possibly null' fields might increase
> performance?
There'd have to be no nulls, period, to get any useful performance
difference --- but yes
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> i.e. for tuple with 100 cols, allocate an array of 100 pointers, plus
>> keep count of how many are actually valid,
> Additionally, this should also make repeted determining of NULL fields
> faster - just put a NULL-pointer in and voila - no more bit-sh
>>>Hannu Krosing said:
> Tom Lane kirjutas N, 23.01.2003 kell 02:04:
> > We already do cache column offsets when they are fixed. The code that's
> > the problem executes when there's a variable-width column in the table
> > --- which means that all columns to its right are not at fixed offsets
Hannu Krosing kirjutas N, 23.01.2003 kell 12:11:
> make the pointer array incrementally for O(N) performance:
>
> i.e. for tuple with 100 cols, allocate an array of 100 pointers, plus
> keep count of how many are actually valid,
Additionally, this should also make repeted determining of NULL fie
Tom Lane kirjutas N, 23.01.2003 kell 02:04:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > Maybe I don't really understand the problem, but it seems simple enough
> > to do it once for the whole query.
>
> We already do cache column offsets when they are fixed. The code that's
> the problem exec
Tom Lane kirjutas N, 23.01.2003 kell 02:18:
> "Dann Corbit" <[EMAIL PROTECTED]> writes:
> > Why not waste a bit of memory and make the row buffer the maximum
> > possible length?
> > E.g. for varchar(2000) allocate 2000 characters + size element and point
> > to the start of that thing.
>
> Surely
[snip]
> For the disk case, why not have the start of the record
> contain an array of offsets to the start of the data for each
> column? It would only be necessary to have a list for
> variable fields.
>
> So (for instance) if you have 12 variable fields, you would
> store 12 integers at th
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> For the disk case, why not have the start of the record contain an array
> of offsets to the start of the data for each column? It would only be
> necessary to have a list for variable fields.
No, you'd need an entry for *every* column (or at least, eve
[snip]
> So (for instance) if you have 12 variable fields, you would
> store 12 integers at the start of the record.
Additionally, you could implicitly size the integers from the properties
of the column. A varchar(255) would only need an unsigned char to store
the offset, but a varchar(8) w
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 22, 2003 4:18 PM
> To: Dann Corbit
> Cc: Steve Crawford; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Terrible performance on wide selects
>
&g
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Why not waste a bit of memory and make the row buffer the maximum
> possible length?
> E.g. for varchar(2000) allocate 2000 characters + size element and point
> to the start of that thing.
Surely you're not proposing that we store data on disk that way.
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 22, 2003 4:04 PM
> To: Dann Corbit
> Cc: Steve Crawford; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Terrible performance on wide selects
>
&g
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Maybe I don't really understand the problem, but it seems simple enough
> to do it once for the whole query.
We already do cache column offsets when they are fixed. The code that's
the problem executes when there's a variable-width column in the table
-
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 22, 2003 3:15 PM
> To: Steve Crawford
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Terrible performance on wide selects
>
>
> Steve Crawford sen
Steve Crawford sent me some profiling results for queries involving wide
tuples (hundreds of columns).
> Done, results attached. nocachegetattr seems to be the likely suspect.
Yipes, you can say that again.
% cumulative self self total
time seconds seconds
17 matches
Mail list logo
