Re: [PERFORM] very large db performance question

> IMHO the size of the DB is less relevant than the query workload. For > example, if you're storying 100GB of data but only doing a single > index scan on it every 10 seconds, any modern machine with enough HD > space should be fine. I agree that the workload is likely to be the main issue in mos

Re: [PERFORM] optimizing large query with IN (...)

> UPDATE table SET table.par = table.par + 1 > WHERE table.key IN ('value1', 'value2', ... , 'value1200' ) How fast is the query alone, i.e. SELECT * FROM table WHERE table.key IN ('value1', 'value2', ... , 'value1200' ) ---(end of broadcast)

Re: [PERFORM] Fixed width rows faster?

> This is bogus reasoning. The limit on index entry length will not > change when you rebuild the index. What I meant by 'rebuilding' was not issuing a REINDEX command, but creating a new index after having dropped the index and inserted whatever records. Building indexes can be slow, and I'd rat

Re: [PERFORM] Fixed width rows faster?

> Frankly, the only reason to use anything other than TEXT is > compatibility with other databases and applications. The main reason why I am still using VARCHAR rather than TEXT in many places is to ensure that the column can be indexed. Postgres, it seems, refuses to insert a string that is long

Re: [PERFORM] Slow join using network address function

> is a datatype that contains > a range of IPv4 addresses, and which has the various operators to > make it GIST indexable. Great, this looks very promising. > No cast operators between ipr and inet types. Any way to work around this, short of dumping a

[PERFORM] Slow join using network address function

I'm trying to join two tables on an inet column, where one of the columns may contain a subnet rather than a single host. Somehow the operation isn't completing quite fast enough, even though neither table is very large: table| rows + clients

Re: [PERFORM] UPDATE with subquery too slow

> I can't get the following statement to complete with reasonable time. Upgraded to 7.4.1, and realized that NOT IN is far more efficient than IN, EXISTS or NOT EXISTS, at least for the amount and distribution of data that I have. Here are some numbers from before and after performing the problema

[PERFORM] UPDATE with subquery too slow

I can't get the following statement to complete with reasonable time. I've had it running for over ten hours without getting anywhere. I suspect (hope) there may be a better way to accomplish what I'm trying to do (set fields containing unique values to null): UPDATE requests SET session = NUL

[PERFORM] Index creation

pping and later recreating each index? -- Eric Jain ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])