Ühel kenal päeval, L, 2006-03-04 kell 10:31, kirjutas Tom Lane:
> Martijn van Oosterhout writes:
> > On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
> >> Also getting rid of toast index and start using ctids directly would be
> >> a big bonus.
> >> When using direct ctids we could u
Martijn van Oosterhout writes:
> On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
>> Also getting rid of toast index and start using ctids directly would be
>> a big bonus.
>> When using direct ctids we could use either ctid chains or some sort of
>> skiplist for access to N-th TOAST
On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
> Also getting rid of toast index and start using ctids directly would be
> a big bonus.
>
> When using direct ctids we could use either ctid chains or some sort of
> skiplist for access to N-th TOAST chunk.
I suppose this would mean
Ühel kenal päeval, N, 2006-03-02 kell 22:15, kirjutas Bruce Momjian:
> Is there still interst in this idea for TODO?
Just to voice my support - Yes, I think that being able to set lower
thresolds for TOAST is very useful in several cases.
Also getting rid of toast index and start using ctids dire
If this would be accepted I might actually be able to accomplish this.
Maybe. :) But having a TODO wouldn't be a bad idea as well...
Would this require 2 new fields in pg_attribute, or is there a better
way to store the thresholds? I'm thinking that each field would need two
special values; 0 for
Is there still interst in this idea for TODO?
---
Jim C. Nasby wrote:
> On Thu, Dec 08, 2005 at 10:03:43AM -0500, Bruce Momjian wrote:
> > Jim C. Nasby wrote:
> > > On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
>
On 12/8/2005 1:42 PM, Jim C. Nasby wrote:
On Thu, Dec 08, 2005 at 10:03:43AM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
> On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > This seems like a useful feature to add, allowing for eas
On Thu, Dec 08, 2005 at 10:03:43AM -0500, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > > This seems like a useful feature to add, allowing for easy built-in
> > > > verticle partitioni
Jim C. Nasby wrote:
> On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > This seems like a useful feature to add, allowing for easy built-in
> > > verticle partitioning. Are there issues with the patch as-is?
> >
> > Other than the ones m
Hello all,
Thank you for having the interest.
Jim C. Nasby wrote:
> Valid point. I do think there's a lot of benefit to being able to set
> the limit much lower than what it currently defaults to today. We have a
> client that has a queue-type table that is updated very frequently. One
> of the f
On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > This seems like a useful feature to add, allowing for easy built-in
> > verticle partitioning. Are there issues with the patch as-is?
>
> Other than the ones mentioned by the poster?
>
> It
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> This seems like a useful feature to add, allowing for easy built-in
> verticle partitioning. Are there issues with the patch as-is?
Other than the ones mentioned by the poster?
It seemed to me more like a not-too-successful experiment than something
re
This seems like a useful feature to add, allowing for easy built-in
verticle partitioning. Are there issues with the patch as-is? (Other
than it probably should have gone to -patches...)
On Thu, Dec 01, 2005 at 05:59:08PM +0900, Junji TERAMOTO wrote:
> Hi all,
>
> I wrote a experimental patch for
Hi all,
I wrote a experimental patch for a vertical partitioning
function.
I decided to use the code of TOAST to create the function
easily. In a word, the row that the user specified is forcedly
driven out with TOAST.
The performance gain of 10% was seen by driving out c_data of the
customer ta
14 matches
Mail list logo
