I am also wondering about the ordering and whether that matters.
Can you have he, can, drink as well as drink, he, can
and should they be considered the same? If so you will need a
different tactic.
ordering matters. So the 3-column tactic should work.
Thanks for your advice!
On Fri, Feb 22, 2008 at 8:48 PM, Dean Gibson (DB Administrator)
[EMAIL PROTECTED] wrote:
On 2008-02-22 12:49, Kynn Jones wrote:
Of course, I expect that using views Vint1 and Vint2... would
result in a loss in performance relative to a version that used bona
fide tables Tint1 and Tint2.
On Fri, Feb 22, 2008 at 8:48 PM, Dean Gibson (DB Administrator)
[EMAIL PROTECTED] wrote:
On 2008-02-22 12:49, Kynn Jones wrote:
Of course, I expect that using views Vint1 and Vint2... would
result in a loss in performance relative to a version that used bona
fide tables Tint1 and Tint2.
On 2008-02-23 05:59, Kynn Jones wrote:
On Fri, Feb 22, 2008 at 8:48 PM, Dean Gibson (DB Administrator)
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
...
Since you have experience working with views, let me ask you this.
The converse strategy to the one I described originally would
On 2008-02-23 07:08, Dean Gibson (DB Administrator) wrote:
...
SELECT word1, word1
FROM S JOIN txt ON word = word1
WHERE type1 = int1 AND type2 = int2;
...
Oops that should be:
SELECT word1, word2
FROM S JOIN txt ON word = word1
WHERE type1 = int1 AND type2 = int2;
--
Mail to my
Hi, Dean. The system I'm working with is very similar in spirit to a
large multilingual dictionary covering 100 languages. Using this analogy,
the type column would correspond to the language, and the zipk column
would correspond to some language-independent key associated with a concept
On 2008-02-23 08:21, Kynn Jones wrote:
...
3. Why not write:
CREATE VIEW txt AS
SELECT a1.word AS word1, a1.type AS type1, a2.word AS word2,
a2.type AS type2
FROM T a1 [LEFT] JOIN T a2 USING( zipk ); -- Use LEFT if
appropriate
SELECT word1, word1
FROM S
On 2008-02-23 08:49, Dean Gibson (DB Administrator) wrote:
Why 10,000 views??? What's wrong with the ONE view above? You DON'T
want to be defining VIEWs based on actual tables VALUES; leave that
to the SELECT. For that matter, what's wrong with the final SELECT I
listed (below)?
SELECT
Hi,
I'm noticing a strange increase in the amount of time it takes to
issue a NOTIFY statement.
I have an existing app that provides a producer / consumer type of
queue and that uses the LISTEN / NOTIFY mechanism to signal the
consumers of new items arriving in the queue. The consumers
Joel Stevenson [EMAIL PROTECTED] writes:
I have an existing app that provides a producer / consumer type of
queue and that uses the LISTEN / NOTIFY mechanism to signal the
consumers of new items arriving in the queue. The consumers then
process these items and issue a notify to signal that
At 11:58 PM -0500 2/23/08, Tom Lane wrote:
Joel Stevenson [EMAIL PROTECTED] writes:
That's strange, I would not have thought that listen/notify behavior
would change at all. How are you measuring this delay exactly?
Can you put together a self-contained test case?
Attached is a perl
11 matches
Mail list logo
