Re: [PERFORM] How to optimize monstrous query, sorts instead of using index

2003-06-25 Thread Tom Lane
?version=7.3idoc=0file=explicit-joins.html regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] problem with pg_statistics

2003-06-26 Thread Tom Lane
will be affected by caching. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] problem with pg_statistics

2003-06-26 Thread Tom Lane
Manfred Koizar [EMAIL PROTECTED] writes: On Thu, 26 Jun 2003 10:08:05 -0400, Tom Lane [EMAIL PROTECTED] wrote: Try reducing random_page_cost With index scan cost being more than 25 * seq scan cost, I guess that - all other things held equal - even random_page_cost = 1 wouldn't help. Oh

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-07-03 Thread Tom Lane
at... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] PostgreSQL vs. MySQL

2003-07-04 Thread Tom Lane
bit looking for answers and tried all the standard answers. It was still much much much slower. Could we see the details? It's not very fair to not give us a chance to learn about problems. regards, tom lane ---(end of broadcast

Re: [PERFORM] PostgreSQL vs. MySQL

2003-07-04 Thread Tom Lane
helped. I suspect he'd made up his mind already. Which is his privilege, but it'd be nice to have some clue what the problem was ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives

Re: [PERFORM] PostgreSQL vs. MySQL

2003-07-04 Thread Tom Lane
, if only so I can try to fix it in future releases, but without useful information I'll just have to write this off as an unsubstantiated report. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] force the use of a particular index

2003-07-11 Thread Tom Lane
use? Would you show us EXPLAIN ANALYZE results when using each index? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] force the use of a particular index

2003-07-11 Thread Tom Lane
due to out-of-date statistics ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message

Re: [PERFORM] [NOVICE] Optimizer Parameters

2003-07-12 Thread Tom Lane
Martin Foster [EMAIL PROTECTED] writes: As a side note, would you recommend disabling fsync for added performance? Only if you are willing to sacrifice crash-safety in the name of speed. regards, tom lane ---(end of broadcast

Re: [PERFORM] optimizer picks smaller table to drive nested loops?

2003-07-14 Thread Tom Lane
not quite sure where the time is going in that case. (Hmmm... time to get out the profiler...) regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe

Re: [PERFORM] optimizer picks smaller table to drive nested loops?

2003-07-14 Thread Tom Lane
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: However, it looks to me like the subquery-scan-outside plan probably is the faster one, on both my machine and yours. I get Woah, that's pretty whacky. It seems like it ought to be way faster to do a single sequential

Re: [PERFORM] Bad performance using ODBC

2003-07-16 Thread Tom Lane
hearing that that adds a heck of a lot of overhead... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] index / sequential scan problem

2003-07-17 Thread Tom Lane
the planner from choosing that alternative if there is any other. The 1.00 is that artificial penalty. We could probably hide this implementation detail from you if we tried hard enough, but it hasn't bothered anyone enough to try. regards, tom lane

Re: [PERFORM] index / sequential scan problem

2003-07-17 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] Relation of indices to ANALYZE

2003-07-17 Thread Tom Lane
code I'd recommend recreating the indexes before you ANALYZE. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] index / sequential scan problem

2003-07-18 Thread Tom Lane
inflating all the cpu_xxx costs by the same factor, unless you have evidence that they are wrong in relation to each other. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http

Re: [PERFORM] Clearing rows periodically

2003-07-18 Thread Tom Lane
of? Only possible if you don't have the FSM parameters set high enough. Infrequent vacuuming means you need more FSM space, btw. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives

Re: File systems (RE: [PERFORM] Sanity check requested)

2003-07-18 Thread Tom Lane
on HPUX (with a SCSI disk) and Linux (with an IDE disk, and a different filesystem). I didn't see too much difference between 'em. RAID might alter the equation, or not. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe

Re: [PERFORM] Poor delete performance AFTER vacuum analyze

2003-07-20 Thread Tom Lane
analyze', the whole thing slows WAY down to where each run can take 10-15 minutes. Could we see EXPLAIN ANALYZE for the deletion query in both the fast and slow states? regards, tom lane ---(end of broadcast)--- TIP 8: explain

Re: [PERFORM] Poor delete performance AFTER vacuum analyze

2003-07-20 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Optimizer differences between 7.2 and 7.3

2003-07-21 Thread Tom Lane
=?ISO-8859-1?Q?SZUCS_G=E1bor?= [EMAIL PROTECTED] writes: do regex ops (~, ~*) use index scan in non-C locales? Is it worth to convert LIKE to regex? The locale issues are the same either way. regards, tom lane ---(end of broadcast

Re: [PERFORM] factoring problem with view in 7.3.3 [ PARTIALLY SOLVED ]

2003-07-23 Thread Tom Lane
the casting quite right? (For instance, timestamp isn't timestamp with time zone ...) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Tuning PostgreSQL

2003-07-26 Thread Tom Lane
contents. PG's WAL logic can recover lost file contents, but we have no way to help out the filesystem if it's lost metadata. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Mapping a database completly into Memory

2003-07-27 Thread Tom Lane
disk block it's ever read. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Mapping a database completly into Memory

2003-07-28 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] Mapping a database completly into Memory

2003-07-28 Thread Tom Lane
a slew of issues of its own. It might happen but I'm not holding my breath. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] [ADMIN] Rebuild indexes

2003-07-28 Thread Tom Lane
that the table knows about new indexes. You do not need to ANALYZE to get the system to notice new indexes. 4. i wish i had a rename index command to rename _swap to its original index name. You can rename indexes as if they were tables. regards, tom lane

Re: [PERFORM] Why performance improvement on converting subselect to a function ?

2003-07-29 Thread Tom Lane
706101 :funcresulttype 23 :funcretset false ... (etc etc) Would you do that and send it along? I'm curious ... But i feel it can be lot more faster , can anyone suggest me something to try. Create an index on old_company_id, perhaps. regards, tom lane

Re: [PERFORM] Why performance improvement on converting subselect to a function ?

2003-07-29 Thread Tom Lane
Rajesh Kumar Mallah [EMAIL PROTECTED] writes: Tom Lane wrote: Odd. Apparently the planner is picking a better plan in the function context than in the subselect context --- which is strange since it ought to have less information. [ verbose plan snipped ] Well, that sure seems

Re: [PERFORM] EXTERNAL storage and substring on long strings

2003-07-31 Thread Tom Lane
.) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] EXTERNAL storage and substring on long strings

2003-07-31 Thread Tom Lane
the profile depends on statistical sampling. I like to have about a minute of accumulated runtime before trusting the results. Repeat the same query multiple times if needed. regards, tom lane ---(end of broadcast)--- TIP 2: you can

Re: [SQL] [PERFORM] EXTERNAL storage and substring on long strings

2003-08-04 Thread Tom Lane
. I'd really like to see some profiling of the poor-performing external-storage case, so we can figure out what's going on. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send

Re: [PERFORM] I can't wait too much: Total runtime 432478.44 msec

2003-08-04 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] I can't wait too much: Total runtime 432478.44 msec

2003-08-04 Thread Tom Lane
, fecha_publicacion DESC) AS ss ORDER BY fecha_publicacion desc LIMIT 10 OFFSET 0 See the weather reports example in the SELECT reference page for motivation. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your

Re: [PERFORM] Some vacuum tuning help

2003-08-06 Thread Tom Lane
the trouble. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] Some vacuum tuning help

2003-08-06 Thread Tom Lane
to find out what works well and what features are needed. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] EXTERNAL storage and substring on long strings

2003-08-06 Thread Tom Lane
Joe Conway [EMAIL PROTECTED] writes: Tom Lane wrote: Ah-hah, I've sussed it ... you didn't actually change the storage representation. You wrote: Yeah, I came to the same conclusion this morning (update longdna set dna = dna || '';), but it still seems that the chunked table is very

Re: [PERFORM] How to efficiently duplicate a whole schema?

2003-08-07 Thread Tom Lane
Sebastien Lemieux [EMAIL PROTECTED] writes: On Wed, 6 Aug 2003, Tom Lane wrote: The idea here is to make sure that the planner's statistics reflect the full state of the table, not the empty state. Otherwise it may pick plans for the foreign key checks that are optimized for small tables. I

Re: [PERFORM] How to efficiently duplicate a whole schema?

2003-08-07 Thread Tom Lane
scott.marlowe [EMAIL PROTECTED] writes: On Wed, 6 Aug 2003, Tom Lane wrote: One obvious question is whether you have your foreign keys set up efficiently in the first place. As a rule, the referenced and referencing columns should have identical datatypes and both should be indexed. (PG

Re: [PERFORM] Some vacuum tuning help

2003-08-14 Thread Tom Lane
... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Some vacuum tuning help

2003-08-14 Thread Tom Lane
...) regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [PERFORM] Moving postgresql.conf tunables into 2003...

2003-08-14 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] How to efficiently duplicate a whole schema?

2003-08-14 Thread Tom Lane
; TRUNCATE table; INSERT new data; The idea here is to make sure that the planner's statistics reflect the full state of the table, not the empty state. Otherwise it may pick plans for the foreign key checks that are optimized for small tables. regards, tom lane

Re: [PERFORM] Odd problem with performance in duplicate database

2003-08-14 Thread Tom Lane
Josh Berkus [EMAIL PROTECTED] writes: Still, they are differences. Attached. Actually, it was mainly cases that I wanted to know about --- specifically, whichever columns are in idx_cases_tgroup. Also, which of the trial_groups columns is the pkey? regards, tom lane

Re: [PERFORM] Odd problem with performance in duplicate database

2003-08-14 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] Perfomance Tuning

2003-08-14 Thread Tom Lane
. Journalling file contents updates, as opposed to filesystem metadata, should be redundant with what we do in WAL. So I'd recommend journalling metadata only, if that option is available (and if Postgres stuff is the only stuff on the disk...) regards, tom lane

Re: [PERFORM] EXTERNAL storage and substring on long strings

2003-08-14 Thread Tom Lane
: 37383.02 ms scott=# So it looks like the external-storage optimization for substring() does work as expected, once you get the data into the right format ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Tom Lane
? And what PG version is this, exactly? regards, tom lane PS: in case you don't know this already, an easy way to get back to the un-analyzed state is DELETE FROM pg_statistics. ---(end of broadcast)--- TIP 1: subscribe

Re: [PERFORM] Odd problem with performance in duplicate database

2003-08-14 Thread Tom Lane
an update to 7.3.4 would be a more profitable use of time. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] PostgreSQL performance problem - tuning

2003-08-14 Thread Tom Lane
of the bizarre-looking cost estimates. I don't recommend setting it false as a system-wide setting. If you want to nudge the planner towards indexscans, reducing random_page_cost a little is probably a better way. regards, tom lane ---(end

Re: [PERFORM] Perfomance Tuning

2003-08-14 Thread Tom Lane
to the filesystem change and how much to the hardware change. But I'd bet 20 disks on fibre array have way more net throughput than a single RAID array on scsi. regards, tom lane ---(end of broadcast)--- TIP 9: the planner

Re: [PERFORM] Analyze makes queries slow...

2003-08-14 Thread Tom Lane
; explain analyze ... query ... If it finishes in a reasonable amount of time, send the explain output. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate

Re: [PERFORM] PostgreSQL performance problem - tuning

2003-08-14 Thread Tom Lane
SELECT performance one bit. It would only affect transactions that modify the database. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Sorting a query on a view ignores an index

2003-08-21 Thread Tom Lane
, the query will try to sort _again_ _without_ index and thus lose all performance. This is a limitation of the 7.3 query planner. 7.4 should do better. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your

Re: [PERFORM] Sorting a query on a view ignores an index

2003-08-21 Thread Tom Lane
list. That's what's preventing 7.3 from doing a good job. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL

Re: [PERFORM] Query too slow

2003-08-26 Thread Tom Lane
could highlight nodes based on a large difference between estimated and actual percentage, or just highlight the nodes that are more than X percent of the runtime. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget

Re: [PERFORM] Sun vs a P2. Interesting results.

2003-08-28 Thread Tom Lane
, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] Indexing question

2003-08-29 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

Re: [PERFORM] PL/pgSQL functions - text / varchar - havy performance

2003-08-29 Thread Tom Lane
= varchar. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] bad estimates

2003-08-30 Thread Tom Lane
sort_mem. Multiple aggregates take more RAM to process in a hashtable style ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] Selecting random rows efficiently

2003-08-30 Thread Tom Lane
. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] How to force Nested Loop plan?

2003-08-30 Thread Tom Lane
the planner recognizes that the new index matches the ORDER BY request). Then you should get a plan with a much smaller cost coefficient for this step. regards, tom lane PS: does server_id really need to be NUMERIC? Why not integer, or at worst bigint

Re: [PERFORM] Selecting random rows efficiently

2003-08-30 Thread Tom Lane
condition has to use stable or immutable functions. By marking oneshot_random() stable, you essentially say that it's okay to evaluate it only once per query, rather than once at each row. regards, tom lane ---(end of broadcast

Re: [PERFORM] How to force Nested Loop plan?

2003-08-30 Thread Tom Lane
Rob Nagler [EMAIL PROTECTED] writes: Tom Lane writes: The reason the planner does not much like this plan is that it's estimating that quite a lot of rows will have to be hit in min_date_time order before it finds enough rows with server_id = 21. Very interesting. How does it know quite

Re: [PERFORM] How to force Nested Loop plan?

2003-08-30 Thread Tom Lane
reduces the actual cost of the indexscan (since visiting the rows in index order becomes less of a random-access proposition). We are aware that the planner doesn't model this effect very well at present ... regards, tom lane ---(end of broadcast

Re: [PERFORM] How to force Nested Loop plan?

2003-09-01 Thread Tom Lane
Rob Nagler [EMAIL PROTECTED] writes: Are there plans for explicit hints to the planner? Personally, I'm philosophically opposed to planner hints; see previous discussions in the archives. regards, tom lane ---(end of broadcast

Re: [PERFORM] How to force Nested Loop plan?

2003-09-01 Thread Tom Lane
) how many tuples a given WHERE predicate resolves to. Why is that better than our existing implementation of column statistics? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map

Re: [PERFORM] Use of to_timestamp causes full scan

2003-09-02 Thread Tom Lane
into a range query: where begin_time ... AND begin_time 'infinity'; See the archives for more discussion. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] PostgreSQL is slow...HELP

2003-09-03 Thread Tom Lane
Azlin Ghazali [EMAIL PROTECTED] writes: Below is the exact statement I used: That's not very informative. Could we see the results of EXPLAIN ANALYZE on that SELECT? Also, what PG version are you running? regards, tom lane ---(end of broadcast

Re: [PERFORM] PostgreSQL Reliability when fsync = false on Linux-XFS

2003-09-04 Thread Tom Lane
. Will that increase any throughput? Probably not... Also, doesn't flash memory have a very limited lifetime in write cycles? Using it as WAL, you'd wear it out PDQ. regards, tom lane ---(end of broadcast)--- TIP 6: Have you

Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic (continued)

2003-09-05 Thread Tom Lane
ANALYZE to make the same random sampling every time. Also, it'd be a good idea to ANALYZE the needed tables by name, explicitly, to ensure that they are analyzed in a known order rather than whatever order ANALYZE happens to find them in pg_class. regards, tom lane

Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic

2003-09-05 Thread Tom Lane
an explicit srandom with a random seed every time through the optimizer, which is the code's default behavior at the moment. That just decreases the randomness AFAICS, compared to letting the established sequence run. regards, tom lane ---(end

Re: [PERFORM] Serious issues with CPU usage

2003-09-05 Thread Tom Lane
10% of the rows in a table since your last vacuum. A VACUUM FULL is a remedy to this problem, but a simple VACUUM isn't. I find that odd; maybe there's something else going on here. But you've not given enough details to speculate. regards, tom lane

Re: [PERFORM] [GENERAL] Seq scan of table?

2003-09-05 Thread Tom Lane
business. See, eg, the thread starting here: http://archives.postgresql.org/pgsql-hackers/2002-11/msg00468.php regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http

Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic

2003-09-07 Thread Tom Lane
is to find a representative dataset. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Serious issues with CPU usage

2003-09-08 Thread Tom Lane
that. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [PERFORM] slow plan for min/max

2003-09-08 Thread Tom Lane
). regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] slow plan for min/max

2003-09-08 Thread Tom Lane
) into some code somewhere, but a patch that approached it that way would be rejected as unmaintainable. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] slow plan for min/max

2003-09-08 Thread Tom Lane
not volunteering to try to code it up ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [PERFORM] Quick question

2003-09-08 Thread Tom Lane
. But I'm slightly concerned about changing the semantics of existing queries. If someone can produce proof that this is allowed (or even better, required) by the SQL spec, it'd be easier... regards, tom lane ---(end of broadcast

Re: [PERFORM] Need advice about triggers

2003-09-09 Thread Tom Lane
result for a typical update command? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] Attempt at work around of int4 query won't touch int8 index ...

2003-09-10 Thread Tom Lane
with this afternoon was removing the int8-and-int4 comparison operators from pg_operator. It works as far as making int8col = 42 do the right thing, but I'm not sure yet about side-effects. regards, tom lane ---(end of broadcast)--- TIP 4

Re: [PERFORM] restore time: sort_mem vs. checkpoing_segments

2003-09-15 Thread Tom Lane
that the disk throughput triples during the checkpoint. Hm, better make sure the log includes some indication of when checkpoints happen. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Attempt at work around of int4 query won't touch int8 index ...

2003-09-16 Thread Tom Lane
heard of before ;-).) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] [GENERAL] how to get accurate values in pg_statistic

2003-09-16 Thread Tom Lane
Mary Edie Meredith [EMAIL PROTECTED] writes: Is there any option to remove the cost numbers from the plan so we can just use diff to automate the plan comparisons? No, but a few moments with sed or perl should get the job done for you. regards, tom lane

Re: [PERFORM] inferior SCSI performance

2003-09-17 Thread Tom Lane
to disk. The performance differential may thus be coming at the expense of reliability. If you run Postgres with fsync off, does the differential go away? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off

Re: [PERFORM] Many fields in one table or many tables?

2003-09-18 Thread Tom Lane
that. You could hit this even with ~100-column tables if you try to select all columns from a join of two or more. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http

Re: [PERFORM] How to force an Index ?

2003-09-18 Thread Tom Lane
promise that doing so wouldn't break things. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [PERFORM] upping checkpoints on production server

2003-09-24 Thread Tom Lane
a drag on performance. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [HACKERS] [PERFORM] osdl-dbt3 run results - puzzled by the execution

2003-09-24 Thread Tom Lane
can't do it alone. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] Index problem

2003-09-25 Thread Tom Lane
.) regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] performance hit when joining with a view?

2003-09-25 Thread Tom Lane
, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

Re: [PERFORM] TPC-R benchmarks

2003-09-25 Thread Tom Lane
dunno whether the TPC rules allow for significant manual rewriting of the given query. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail

Re: [PERFORM] Indices arent being used

2003-09-26 Thread Tom Lane
, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [PERFORM] Indices arent being used

2003-09-27 Thread Tom Lane
to cancel the query after 10 min. Force use of the indexes is not always an answer to performance issues. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate

Re: [PERFORM] Performance: BigInt vs Decimal(19,0)

2003-09-27 Thread Tom Lane
not normally much need for apps to be explicitly aware of the column type names. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [PERFORM] TPC-R benchmarks

2003-09-29 Thread Tom Lane
to see. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through

Re: [PERFORM] Test...

2003-09-29 Thread Tom Lane
nothing, there's a configuration problem with the pg-perform mail list or your subscription or something. Talk to Marc (scrappy at hub.org) about identifying and fixing the issue. regards, tom lane ---(end of broadcast

Re: [PERFORM] Tuning/performance issue...

2003-10-01 Thread Tom Lane
and user_account.user_role_id. The trick is to apply those before joining any other tables. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

  1   2   3   4   5   6   7   8   9   10   >