Bruno Wolff III <[EMAIL PROTECTED]> writes:
> 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/
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
>
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, increa
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?
Y
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 an
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 (c
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) le
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 broadcast)
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 r
'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 writtenDa
David Jaquay <[EMAIL PROTECTED]> writes:
> Summary: Doing a two or three table join for a date range performs
> worse than doing the same query individually for each date in the
> range.
Could we see EXPLAIN ANALYZE, not just EXPLAIN, results?
Also, have you ANALYZEd lately? If the estimated row
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
Summary: Doing a two or three table join for a date range performs
worse than doing the same query individually for each date in the
range.
What works: Doing a query just on a single date or a date range
(against just one table) runs quick; 'explain' says it uses an index
scan. Doing a query on a
13 matches
Mail list logo
