David,
The problem: Doing a query for a date range on a particular store or
market, though, for a date range of more than a few days does a
sequential scan of sales_tickets, and performs worse than doing one
single date query for each date. My 'explain' for one such query is
below.
Can you
'explain analyze' output is below. I have done analyze recently, and
am using pg 7.4.2 on SuSE 9.1. I'd be curious to know how to a
nestloop indexscan to try it out.
Thanks,
Dave
mydb= explain analyze select * from line_items t, sales_tickets s
where writtenDate = '12/01/2002' and writtenDate
Dave,
Ah
- Seq Scan on sales_tickets s (cost=0.00..89543.50
rows=626783 width=12) (actual time=38.017..19387.447 rows=713846
loops=1)
This is just more than 1/2 the time of your query. The issue is that you're
pulling 713,000 rows (PG estimates 626,000 which is in the
I use RH 9.0 with postgresql 7.3.2 and 4 Gb ram [server spec. Dual Xeon 3.0]
and someone mention that the hyperthreading will not help but if I let it there
will it be any harm to the system?
Any comment please.
Amrit
Thailand
---(end of
Amrit,
I use RH 9.0 with postgresql 7.3.2 and 4 Gb ram [server spec. Dual Xeon
3.0] and someone mention that the hyperthreading will not help but if I let
it there will it be any harm to the system?
Any comment please.
Sometimes. Run a test and take a look at your CS (context switch)
Josh Berkus wrote:
Amrit,
I use RH 9.0 with postgresql 7.3.2 and 4 Gb ram [server spec. Dual Xeon
3.0] and someone mention that the hyperthreading will not help but if I let
it there will it be any harm to the system?
Any comment please.
Sometimes. Run a test and take a look at your CS
Do large TEXT or VARCHAR entries in postgresql cause any performance
degradation when a query is being executed to search for data in a table
where the TEXT/VARCHAR fields aren't being searched themselves?
Since, according to the postgresql docs, theirs no performance
difference between VARCHAR
On Fri, Jan 07, 2005 at 19:36:47 -0800,
Loren M. Lang [EMAIL PROTECTED] wrote:
Do large TEXT or VARCHAR entries in postgresql cause any performance
degradation when a query is being executed to search for data in a table
where the TEXT/VARCHAR fields aren't being searched themselves?
Yes in
I guess my question that would follow is, when does it work best to
start using BLOBs/CLOBs (I forget if pg has CLOBs) instead of
textfields because your table is going to balloon in disk blocks if
you have large amounts of data, and all fields you want to search on
would have to be indexed,
On Fri, Jan 07, 2005 at 10:03:23PM -0600, Bruno Wolff III wrote:
On Fri, Jan 07, 2005 at 19:36:47 -0800, Loren M. Lang [EMAIL PROTECTED]
wrote:
Since, according to the postgresql docs, theirs no performance
difference between VARCHAR and TEXT, I'm assuming VARCHAR is identical
to TEXT
10 matches
Mail list logo
