On Jul 21, 6:06 am, scott.marl...@gmail.com (Scott Marlowe) wrote:
> On Mon, Jul 20, 2009 at 9:35 PM, Krade wrote:
> > But I think I might just do:
> > select * from a where comment_tsv @@ plainto_tsquery('query') and timestamp
> >> cast(floor(extract(epoch from CURRENT_TIMESTAMP) - 864000) as inte
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
is still present in 8.4 or if some tunable (or other) made the use of
hyperthreading a non-issue. We're looking to upgrade our servers soon
for performance reasons and am trying to determ
On Mon, 20 Jul 2009, Kevin Grittner wrote:
Oh, well, if you load all the data into Java's heap and are accessing
it through HashMap or similar, I guess a factor of 100 is about right.
No, that's not what I'm doing. Like I said, I have implemented the very
same algorithm as in Postgres, emulati
On Tue, Jul 21, 2009 at 1:42 PM, Doug Hunley wrote:
> Just wondering is the issue referenced in
> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
> is still present in 8.4 or if some tunable (or other) made the use of
> hyperthreading a non-issue. We're looking to upgrade our
On Tue, 21 Jul 2009, valgog wrote:
There is a problem with GIN and GIST indexes, that they cannot be used
by the ORDER BY. Maybe it will be a nice idea to ask Oleg to make it
possible to use the b-tree columns in GIST or GIN to make the sort
easier, but I have no idea how difficult it will be to
Matthew Wakeling wrote:
> I have implemented the very same algorithm as in Postgres, emulating
> index pages and all.
> The java program uses as near an on-disc format as Postgres does -
> just held in memory instead of in OS cache.
Interesting. Hard to explain without a lot more detail.
On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
> Just wondering is the issue referenced in
> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
> is still present in 8.4 or if some tunable (or other) made the use of
> hyperthreading a non-issue. We're looking to upgrade our
2009/7/21 Grzegorz Jaśkiewicz :
> On Tue, Jul 21, 2009 at 1:42 PM, Doug Hunley wrote:
>> Just wondering is the issue referenced in
>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>> is still present in 8.4 or if some tunable (or other) made the use of
>> hyperthreading a no
On Tue, Jul 21, 2009 at 3:16 PM, Scott Marlowe wrote:
> On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
>> Just wondering is the issue referenced in
>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>> is still present in 8.4 or if some tunable (or other) made the use of
On 07/21/2009 10:36 AM, Grzegorz Jaśkiewicz wrote:
On Tue, Jul 21, 2009 at 3:16 PM, Scott Marlowe wrote:
On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
Just wondering is the issue referenced in
http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
is still prese
2009/7/21 Mark Mielke :
> On 07/21/2009 10:36 AM, Grzegorz Jaśkiewicz wrote:
>
> On Tue, Jul 21, 2009 at 3:16 PM, Scott Marlowe
> wrote:
>
>
> On Tue, Jul 21, 2009 at 6:42 AM, Doug Hunley wrote:
>
>
> Just wondering is the issue referenced in
> http://archives.postgresql.org/pgsql-performance/2005-
On 7/21/2009 11:32, valgog wrote:
Hi,
There is a problem with GIN and GIST indexes, that they cannot be used
by the ORDER BY. Maybe it will be a nice idea to ask Oleg to make it
possible to use the b-tree columns in GIST or GIN to make the sort
easier, but I have no idea how difficult it will be
On 7/21/09 9:22 AM, "Scott Marlowe" wrote:
>> But, the real point is that "thread" (whether "CoolThread" or "HT" thread),
>> is not the same as core, which is not the same as processor. X 2 threads is
>> usually significantly less benefit than X 2 cores. X 2 cores is probably
>> less benefit t
Scott Carey wrote:
But back on topic for HT -- HT doesn't like spin-locks much unless they
use the right low level instruction sequence rather than actually
spinning. With the right instruction, the spin will allow the other
thread to do work... With the wrong one, it will tie up the pipeline.
On Mon, Jul 20, 2009 at 10:29 AM, Craig James wrote:
> Apologies for a slightly off-topic question ... a friend is overseeing the
> demise of a company and has several computers that they need to get rid of.
> She's an attorney and knows little about them except that they're IBM and
> cost >$50K o
On Tue, 21 Jul 2009, Krade wrote:
On 7/21/2009 11:32, valgog wrote:
Hi,
There is a problem with GIN and GIST indexes, that they cannot be used
by the ORDER BY. Maybe it will be a nice idea to ask Oleg to make it
possible to use the b-tree columns in GIST or GIN to make the sort
easier, but I h
Hi Performance Wizards!
I need advice on this.
I have a db which is being constantly updated and queried by a few
computers. We are doing datamining. The machine is running on a
moderately powered machine and processors constantly hit 90%.
At the same time, we need to present these data on a web
Hi
I'm storing historical meteorological gridded data from GFS (
http://www.nco.ncep.noaa.gov/pmb/products/gfs/) into an array field in a
table like this:
CREATE TABLE grid_f_data_i2 (
//Specifies the variable and other features of data
id_inventory integer REFERENCES grid_d_inventory(id_inve
Victor,
Just wondering why do you use array ?
Oleg
On Wed, 22 Jul 2009, Victor de Buen (Bayes) wrote:
Hi
I'm storing historical meteorological gridded data from GFS (
http://www.nco.ncep.noaa.gov/pmb/products/gfs/) into an array field in a
table like this:
CREATE TABLE grid_f_data_i2 (
//Sp
On Tue, Jul 21, 2009 at 9:47 PM, Kelvin Quee wrote:
> Hi Performance Wizards!
>
> I need advice on this.
>
> I have a db which is being constantly updated and queried by a few
> computers. We are doing datamining. The machine is running on a
> moderately powered machine and processors constantly hi
20 matches
Mail list logo
