On Thu, Jan 29, 2009 at 12:01 AM, Kevin Traster wrote:
> 2 questions:
>
> 1) Different costs for same actions. Doing an explain on 2 nearly identical
> queries both involving the same Index scan on same table has 2 widely
> different costs for same Index scan 303375872.86 vs. 12576.70
Pretty sur
2 questions:
1) Different costs for same actions. Doing an explain on 2 nearly identical
queries both involving the same Index scan on same table has 2 widely
different costs for same Index scan 303375872.86 vs. 12576.70
2) Simple query using NOT IN (subquery)was killed after 2 hrs, using the
sa
On Tue, Jan 27, 2009 at 7:03 AM, M. Edward (Ed) Borasky
wrote:
> M. Edward (Ed) Borasky wrote:
>> Given large amounts of RAM and only PostgreSQL running in the server,
>> the interesting trade-offs become
>>
>> a. How little memory can you buy without putting your service level
>> agreements at ri
On Tue, Jan 27, 2009 at 1:20 AM, A B wrote:
> While browsing the net I found a server with a raid controller
>HP Smart Array P400/512MB BBWC Controller
> How does one know what this is, if it is any good or so? I guess they
> just stuck their "HP" label onto some other raid controller?
> I
On 1/28/09, Phoenix Kiula wrote:
> [Ppsted similar note to PG General but I suppose it's more appropriate
> in this list. Apologies for cross-posting.]
>
> Hi. Further to my bafflement with the "count(*)" queries as described
> in this thread:
>
> http://archives.postgresql.org/pgsql-general/2
Phoenix Kiula wrote:
> [Ppsted similar note to PG General but I suppose it's more appropriate
> in this list. Apologies for cross-posting.]
>
> Hi. Further to my bafflement with the "count(*)" queries as described
> in this thread:
>
> http://archives.postgresql.org/pgsql-general/2009-01/msg00804
> My question: with that kind of volume and the underlying aggregation
> functions (by product id, dates, possibly IP addresses or at least
> countries of origin..) will PG ever be a good choice? Or should I be
> looking at some other kind of tools? I wonder if OLAP tools would be
> overkill for so
> Is there any tweaks to force pgsql to use index on description?
Even if you could force it to use the index, it wouldn't make the
query run faster.
As others have pointed out, what you really need is a different kind of index...
...Robert
--
Sent via pgsql-performance mailing list (pgsql-per
[Ppsted similar note to PG General but I suppose it's more appropriate
in this list. Apologies for cross-posting.]
Hi. Further to my bafflement with the "count(*)" queries as described
in this thread:
http://archives.postgresql.org/pgsql-general/2009-01/msg00804.php
It seems that whenever this q
In response to Hari, Balaji :
> Hi,
>
>
>
> I am relatively new to PostgreSQL(8.1) and facing the following problem.
Sure? 8.1? Your explain looks like 8.2 or 8.3. 8.3 contains a
full-text-search.
If really not 8.3 you can use tsearch2, it is a contrib-module.
Andreas
--
Andreas Kretschmer
On Wed, Jan 28, 2009 at 12:41 AM, Hari, Balaji wrote:
> EXPLAIN ANALYZE SELECT event_id, category, current_session_number,
> description, event_type_id, realm_name, root_session_number, severity,
> source_name, target_key, target_name, timestamp, jdo_version FROM event
> WHERE description like '%m
Hi Mark,
I Rohan Pethkar wants to run some of the DBT2 tests on PostgreSQL. I have
downloaded latest DBT2 tarball from http://git.postgresql.org .
I tried steps from which are there in INSTALL file. cmake CMakeLists.txt
command runs fine.I tried to install DBT2 but getting following exception
whil
12 matches
Mail list logo