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
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.
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
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
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
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
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?
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
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, but
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
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
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
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
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
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
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 to
verify
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 to
verify
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
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
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
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 results on a modest 3800X2 2 Gig
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
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
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
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 to
verify
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
Ü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-case ---
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) for a fairly
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,
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
happy with
30 matches
Mail list logo
