On Wed, 2009-03-11 at 22:20 -0400, Jignesh K. Shah wrote:
> A tunable does not impact existing behavior
Why not put the tunable parameter into the patch and then show the test
results with it in? If there is no overhead, we should then be able to
see that.
--
Simon Riggs www.2ndQuad
Simon Riggs wrote:
On Wed, 2009-03-11 at 22:20 -0400, Jignesh K. Shah wrote:
A tunable does not impact existing behavior
Why not put the tunable parameter into the patch and then show the test
results with it in? If there is no overhead, we should then be able to
see that.
Can
Test hardware:
MB:GA-EP43-DS3L, CPU :intel 7400 RAM:2G HD:320G sata
debian5, freebsd7.1 are installed by default choice by cd-rom
debian use XFS, Freebsd use UFS+softdateup
all software installed by app_get or pkg_add, change NOTHING configure.
at begening of every testing, use initdb create new d
Short summary:
* extremely slow intarray indexes with gist__int_ops
* gist__intbig_ops seems much faster even with short arrays
* gin seems much much faster for inserts and creation(and queries)
I was debugging a system with a table that slowed to where individual
inserts were taking
Ron Mayer wrote:
> This table summarizes some of the times, shown more completely
> in a script below.
> =
> create gist index on 1 = 5 seconds
> create gist index on 2 = 32 seconds
> create gist index on 3 = 39
On 03/16/09 13:39, Simon Riggs wrote:
On Wed, 2009-03-11 at 22:20 -0400, Jignesh K. Shah wrote:
A tunable does not impact existing behavior
Why not put the tunable parameter into the patch and then show the test
results with it in? If there is no overhead, we should then be able to
see that
We have a few slow queries that use sequential scans on tables that have
plenty of indexes (for other queries), on a box with a lot of RAM and 13
active cores (don't ask), so I was curious to find out how to put this
environment to better use. The result is (maybe) interesting, esp. since
Postg
On Tue, 17 Mar 2009, Marinos Yannikos wrote:
It should be easy to implement this for any of the various connection
pooling solutions also.
pgpool-II has something very similar in its "Parallel Mode", and the
example given at
http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-en.html
On Tue, 2009-03-17 at 17:41 -0400, Jignesh K. Shah wrote:
> I did a quick test with patch. Unfortunately it improves my number
> even with default setting 0 (not sure whether I should be pleased or
> sad - Definitely no overhead infact seems to help performance a bit.
> NOTE: Logic is same, imple
Simon Riggs wrote:
On Tue, 2009-03-17 at 17:41 -0400, Jignesh K. Shah wrote:
I did a quick test with patch. Unfortunately it improves my number
even with default setting 0 (not sure whether I should be pleased or
sad - Definitely no overhead infact seems to help performance a bit.
NOTE: Lo
On Tue, 2009-03-17 at 19:54 -0400, Jignesh K. Shah wrote:
>
> Simon Riggs wrote:
> > On Tue, 2009-03-17 at 17:41 -0400, Jignesh K. Shah wrote:
> >
> >
> >> I did a quick test with patch. Unfortunately it improves my number
> >> even with default setting 0 (not sure whether I should be pleased
Ron Mayer writes:
> vm=# create index "gist7" on tmp_intarray_test using GIST (my_int_array
> gist__int_ops);
> CREATE INDEX
> Time: 2069836.856 ms
> Is that expected, or does it sound like a bug to take over
> half an hour to index 7 rows of mostly 5 and 6-element
> integer arrays?
I p
12 matches
Mail list logo
