[PERFORM] seeking advise on char vs text or varchar in search table

[chrisj]

I have a table that contains a column for keywords that I expect to become
quite large and will be used for web searches.  I will either index the
column or come up with a simple hashing algorithm add the hash key to the
table and index that column.

I am thinking the max length in the keyword column I need to support is 30,
but the average would be less than10

Any suggestions on whether to use char(30), varchar(30) or text, would be
appreciated.  I am looking for the best performance option, not necessarily
the most economical on disk.

Or any other suggestions would be greatly appreciated.
-- 
View this message in context: 
http://www.nabble.com/seeking-advise-on-char-vs-text-or-varchar-in-search-table-tf3618204.html#a10103002
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

[PERFORM] using a stored proc that returns a result set in a complex SQL stmt

[chrisj]

Hi,

I am trying to decide between using a temporary table or a stored proc that
returns a result set to solve a fairly complex problem, and was wondering if
Postres, when it sees a stored proc reference in a SQL, is smart enough to,
behind the scenes, create a temporary table with the results of the stored
proc such that the stored proc does not get executed multiple times within a
single query execution??

Example: suppose I had a stored proc called SP_bob that returns a result set
including the column store_no
and I wrote the following query:

select * from Order_Line as X
where not exists (select 1 from SP_bob(parm1, parm2) as Y where X.store_no =
Y.store_no)

Can I rest assured that the stored proc would only run once, or could it run
once for each row in Order_Line??

The only reason I am going down this road is because of the difficulty of
using temp tables ( i.e. needing to execute a SQL string).  Does anyone know
if this requirement may be removed in the near future? 


-- 
View this message in context: 
http://www.nabble.com/using-a-stored-proc-that-returns-a-result-set-in-a-complex-SQL-stmt-tf4628555.html#a13216092
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match