sarlav kumar <[EMAIL PROTECTED]> writes:
> I have a query which does not use index scan unless I force postgres to use
> index scan. I dont want to force postgres, unless there is no way of
> optimizing this query.
The major issue seems to be in the sub-selects:
> -> Seq Scan
But, I'm also still interested in the answer to my question: is there
any reason you could not put an 8.0 tablespace on a RAM disk?
I can imagine doing it by having an initdb run at startup somehow, with
the idea that having a mix of tablespaces in a database would make this
harder, but I haven't
Oh! I sort of started paying attention to that in the middle...and
couldn't make head or tail out of it. Will search back to the
beginning
Thanks.
- DAP
>-Original Message-
>From: Josh Berkus [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 19, 2004 7:35 PM
>To: [EMAIL PROTECTED]
>
David,
> We have a couple tables (holding information about network sessions, for
> instance) which don't need to persist beyond the life of the server, but
> while the server is running they are heavily hit, insert/update/delete.
See the thread this last week on Memcached for a cheaper solution.
The data that we are accessing is via QLogic cards connected to an EMC Clarion.
We have tried it on local SCSI disks with the same (bad) results.
When the machine gets stuck in a 100% IOWAIT state it often crashes soon after
that.
The disks are fine, have been replaced and checked.
Here are m
[EMAIL PROTECTED] (Dawid Kuroczko) writes:
> ALTER TABLE foo ALTER COLUMN bar SET STATISTICS n; .
>
> I wonder what are the implications of using this statement,
> I know by using, say n=100, ANALYZE will take more time,
> pg_statistics will be bigger, planner will take longer time,
> on the ot
We are using 7.4.5 on Solaris 9.
We have a couple tables (holding information about network sessions, for
instance) which don't need to persist beyond the life of the server, but while
the server is running they are heavily hit, insert/update/delete.
Temporary tables won't work for us because
On Fri, 19 Nov 2004, Arshavir Grigorian wrote:
> Hi,
>
> I have a query that when run on similar tables in 2 different databases
> either uses the index on the column (primary key) in the where clause or
> does a full table scan. The structure of the tables is the same, except
> that the table whe
Arshavir Grigorian <[EMAIL PROTECTED]> writes:
> I have a query that when run on similar tables in 2 different databases
> either uses the index on the column (primary key) in the where clause or
> does a full table scan. The structure of the tables is the same, except
> that the table where the
Jan,
> Hmmm ... what type of foreign key lookup would that be? None of the RI
> generated queries has any order by clause.
I was under the impression that work_mem would be used for the index if there
was an index for the RI lookup. Wrong?
--
--Josh
Josh Berkus
Aglio Database Solutions
San
On Thu, 18 Nov 2004 12:14:00 -0500
Dave Cramer <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> Dell's aren't well known for their disk performance, apparently most
> of the perc controllers sold with dell's are actually adaptec
> controllers. Also apparently they do not come with the battery
> required
Hi All,
I am new to Postgres.
I have a query which does not use index scan unless I force postgres to use index scan. I dont want to force postgres, unless there is no way of optimizing this query.
The query :
select m.company_name,m.approved,cu.account_no,mbt.business_name,cda.country,
(s
Thanks for all the replies. It actually has to do with the locales. The
db where the index gets used is running on C vs the the other one that
uses en_US.UTF-8. I guess the db with the wrong locale will need to be
waxed and recreated with correct locale settings. I wonder if there are
any plans
Arshavir,
> I have a query that when run on similar tables in 2 different databases
> either uses the index on the column (primary key) in the where clause or
> does a full table scan. The structure of the tables is the same, except
> that the table where the index does not get used has an extra m
Dawid,
> I wonder what are the implications of using this statement,
> I know by using, say n=100, ANALYZE will take more time,
> pg_statistics will be bigger, planner will take longer time,
> on the other hand it will make better decisions... Etc, etc.
Yep. And pg_statistics will need to be va
On Fri, Nov 19, 2004 at 02:18:55PM -0500, Arshavir Grigorian wrote:
> The 2 boxes where these database run are very different (Sparc with scsi
> disks and 2G RAM running Solaris 8 AND a PC with 128M RAM running and an
> IDE drive running Linux RH9 2.4.20-20.9). I am not sure why that would
> mak
Hi,
I have a query that when run on similar tables in 2 different databases
either uses the index on the column (primary key) in the where clause or
does a full table scan. The structure of the tables is the same, except
that the table where the index does not get used has an extra million
rows
On 11/17/2004 5:07 PM, Josh Berkus wrote:
David,
I understand that the sort_mem conf setting affects queries with order by,
etc., and the doc mentions that it is used in create index. Does sort_mem
affect the updating of indexes, i.e., can the sort_mem setting affect the
performance of inserts?
Onl
ALTER TABLE foo ALTER COLUMN bar SET STATISTICS n; .
I wonder what are the implications of using this statement,
I know by using, say n=100, ANALYZE will take more time,
pg_statistics will be bigger, planner will take longer time,
on the other hand it will make better decisions... Etc, etc.
I
19 matches
Mail list logo
