On Mar 22, 2007, at 7:25 AM, Pavan Deolasee wrote:
Grzegorz, if you can try HOT as well, that will be great.
I tried, and it worked very well with 4.2 v of patch, as I remember.
My point was, since 'the day' comes closer, and you guys work on
close areas inside pg - I would like to be a
On 3/22/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Grzegorz Jaskiewicz wrote:
> any idea how this patch is going to play with hot ? or should I just
> give it a spin, and see if my world collapses :D
I've run tests with both patches applied. I haven't tried with the
latest HOT-versions,
Grzegorz Jaskiewicz wrote:
any idea how this patch is going to play with hot ? or should I just
give it a spin, and see if my world collapses :D
I've run tests with both patches applied. I haven't tried with the
latest HOT-versions, but they should in theory work fine together.
You'll get a c
any idea how this patch is going to play with hot ? or should I just
give it a spin, and see if my world collapses :D
--
Grzegorz Jaskiewicz
C/C++ freelance for hire
---(end of broadcast)---
TIP 4: Have you searched our list archives?
On Mar 21, 2007, at 5:22 PM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd
suggest t
Joshua D. Drake wrote:
Right. My understanding is that the clustered index will gradually
degrade to a normal btree, is that correct heikki?
That's right.
We could of course resolve this by doing a reindex.
Not reindex, but cluster. How clustered the index can be depends on the
clusteredne
Grzegorz Jaskiewicz wrote:
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd suggest
to enable stats_block_level to see the effect on buffer ca
Grzegorz Jaskiewicz wrote:
>
> On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
>
>> Grzegorz Jaskiewicz wrote:
>>> On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd suggest
to enable stats_block_level to see the e
On Mar 19, 2007, at 11:16 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd
suggest to enable stats_block_level to see the effect on buffer
cache hit/miss ratio.
group
Grzegorz Jaskiewicz wrote:
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd suggest to
enable stats_block_level to see the effect on buffer cache hit/miss
ratio.
groupeditems-42-pghead.patch.gz is enough, or it needs
maintai
On Mar 17, 2007, at 10:33 PM, Luke Lonergan wrote:
Wow, nice!
Can you tell us:
- how big is the table
- cardinality of the column
- how big is the index in each case
- how much memory on the machine
- query and explain analyze
All I changed, was the 400k to 150k
512MB of ram, as I said earl
PROTECTED]
Sent: Saturday, March 17, 2007 05:16 PM Eastern Standard Time
To: Joshua D.Drake
Cc: Heikki Linnakangas; PostgreSQL-development Hackers
Subject:Re: [HACKERS] [PATCHES] Bitmapscan changes
This is on dual ultra 2 sparc. with ultrawide 320 scsi drives. 512MB
ram.
I had to
This is on dual ultra 2 sparc. with ultrawide 320 scsi drives. 512MB
ram.
I had to drop size of DB, because the DB drive is 4GB (I do welecome
bigger drives as donation, if someone asks - UWscsi 320).
here are my results. With only 4.2 patch (no maintain cluster order
v5 patch). If the v5 p
Grzegorz Jaskiewicz wrote:
>
> On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
>
>
>>
>> You'll obviously need to run it with the patch applied. I'd suggest to
>> enable stats_block_level to see the effect on buffer cache hit/miss
>> ratio.
>
> groupeditems-42-pghead.patch.gz is enough,
On Mar 16, 2007, at 10:12 PM, Heikki Linnakangas wrote:
You'll obviously need to run it with the patch applied. I'd suggest
to enable stats_block_level to see the effect on buffer cache hit/
miss ratio.
groupeditems-42-pghead.patch.gz is enough, or it needs
maintain_cluster_order_v5.pa
Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
>> Heikki Linnakangas wrote:
>>> Joshua D. Drake wrote:
This URL is not working:
http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
>>> Sorry about that, typo in the filename. Fixed.
>>>
>>>
>> Here are my r
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
This URL is not working:
http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
Sorry about that, typo in the filename. Fixed.
Here are my results on a modest 3800X2 2 Gig of ram, RAID 1 dual SATA
T
Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
>> This URL is not working:
>>
>>
>> http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
>
> Sorry about that, typo in the filename. Fixed.
>
>
Here are my results on a modest 3800X2 2 Gig of ram, RAID 1 dual SATA
http://pg
Joshua D. Drake wrote:
This URL is not working:
http://community.enterprisedb.com/git/git-perfunittests-20070222.tar.gz
Sorry about that, typo in the filename. Fixed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)-
Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
>> This is what I suggest.
>>
>> Provide a tarball of -head with the patch applied.
>
> Here you are:
>
> http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
>
>> Provide a couple of use cases that can be run with explanation of how
Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
>> This is what I suggest.
>>
>> Provide a tarball of -head with the patch applied.
>
> Here you are:
>
> http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
>
>> Provide a couple of use cases that can be run with explanation of how
Heikki Linnakangas wrote:
> Joshua D. Drake wrote:
>> This is what I suggest.
>>
>> Provide a tarball of -head with the patch applied.
>
> Here you are:
>
> http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
>
>> Provide a couple of use cases that can be run with explanation of how
Joshua D. Drake wrote:
This is what I suggest.
Provide a tarball of -head with the patch applied.
Here you are:
http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
Provide a couple of use cases that can be run with explanation of how to
verify the use cases.
There's a number o
Alvaro Herrera wrote:
Which is why we don't do things that way. The code must fit within the
general architecture before application -- particularly if it's an
internal API change. That's what the review process is for.
Yes, of course. As I've said, I have the time to work on this, but I
nee
Hannu Krosing wrote:
Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki
Linnakangas:
Clustered indexes have roughly the same performance effect and use cases
as clustered indexes on MS SQL Server, and Index-Organized-Tables on
Oracle, but the way I've implemented them is significantly
Alvaro Herrera wrote:
> Joshua D. Drake wrote:
>
>> Allow the community to drive the inclusion by making it as easy as
>> possible to allow a proactive argument to take place by the people
>> actually using the product.
>
> This seems to be a rather poor decision making process: "Are the users
>
Joshua D. Drake wrote:
> Allow the community to drive the inclusion by making it as easy as
> possible to allow a proactive argument to take place by the people
> actually using the product.
This seems to be a rather poor decision making process: "Are the users
happy with the new feature? If so,
Hannu Krosing wrote:
> Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki
> Linnakangas:
>> Tom Lane wrote:
>>> At this point I'm feeling unconvinced that we want it at all. It's
>>> sounding like a large increase in complexity (both implementation-wise
>>> and in terms of API ugliness)
Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki
Linnakangas:
> Tom Lane wrote:
> > At this point I'm feeling unconvinced that we want it at all. It's
> > sounding like a large increase in complexity (both implementation-wise
> > and in terms of API ugliness) for a fairly narrow use-ca
Tom Lane wrote:
At this point I'm feeling unconvinced that we want it at all. It's
sounding like a large increase in complexity (both implementation-wise
and in terms of API ugliness) for a fairly narrow use-case --- just how
much territory is going to be left for this between HOT and bitmap ind
30 matches
Mail list logo
