Re: [PERFORM] Talking about optimizer, my long dream

2011-02-06 Thread Mladen Gogala
Please, don't include me on your emails. I unsubscribed from the list. Cédric Villemain wrote: 2011/2/4 Frank Heikens : On 04 Feb, 2011,at 02:56 PM, Mladen Gogala wrote: Віталій Тимчишин wrote: Hi, all. All this optimizer vs hint thread There is no "optimize

Re: [PERFORM] Talking about optimizer, my long dream

2011-02-04 Thread Mladen Gogala
Shaun Thomas wrote: On 02/04/2011 07:56 AM, Mladen Gogala wrote: Hints are a necessary part of the optimizer in all other databases. Without hints Postgres will not get used in the company that I work for, period. I've said repeatedly that EnterpriseDB, a fork of PostgreSQL, ha

Re: [PERFORM] Talking about optimizer, my long dream

2011-02-04 Thread Mladen Gogala
the fatwa against hints seems unyielding, so that's it. I am even inclined to believe that deep down under the hood, this fatwa has an ulterior motive, which disgusts me deeply. With hints, there would be far fewer consulting gigs. Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
Robert Haas wrote: On Thu, Feb 3, 2011 at 6:33 PM, Mladen Gogala wrote: Kevin Grittner wrote: Mladen Gogala wrote: Maybe we can agree to remove that ridiculous "we don't want hints" note from Postgresql wiki? I'd be against that. This is reha

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
Joshua D. Drake wrote: On Thu, 2011-02-03 at 18:33 -0500, Mladen Gogala wrote: Exactly what we don't want. Who is "we"? The majority of long term hackers. If that is so, I don't see "world domination" in the future, exactly

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
Kevin Grittner wrote: Mladen Gogala wrote: Maybe we can agree to remove that ridiculous "we don't want hints" note from Postgresql wiki? I'd be against that. This is rehashed less frequently since that went in. Less wasted time and bandwidth with it there.

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
ted" issue, especially if we have in mind that hints are already here, in the form of "enable_" switches. Link? There's a lot of stuff on the wiki. http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want No. 2 on the list. -- Mladen Gogala Sr. Oracle DBA 15

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
/db2-hints-optimizer-selection.html SQL Server and MySQL too. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@post

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
sue, especially if we have in mind that hints are already here, in the form of "enable_" switches. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-perform

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
Mladen Gogala wrote: Actually, I don't want Oracle hints. Oracle hints are ugly and cumbersome. I would prefer something like this: http://dev.mysql.com/doc/refman/5.0/en/index-hints.html That should also answer the question about other databases supporting hints. Sorry. I forgot

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
refman/5.0/en/index-hints.html That should also answer the question about other databases supporting hints. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-p

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
legant. The hints are there because they are definitely needed. Yet, there is a religious zeal and a fatwa against them. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent v

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
not sure about the world domination thing, though. Optimizer hints are a big feature that everybody else has and Postgres does not have because of religious reasons. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integ

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
Shaun Thomas wrote: On 02/03/2011 10:38 AM, Mladen Gogala wrote: It all boils down to the database. Hints, whether they're well-intentioned or not, effectively cover up bugs in the optimizer, planner, or some other approach the database is using to build its execution. Hints don&#x

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
Chris Browne wrote: It's worth looking back to what has already been elaborated on in the ToDo. And that precisely is what I am trying to contest. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-03 Thread Mladen Gogala
Greg Smith wrote: Mladen Gogala wrote: The techies at big companies are the guys who will or will not make it happen. And these guys are not beginners. Appeasing them may actually go a long way. The PostgreSQL community isn't real big on appeasing people if it's at the

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
r will not make it happen. And these guys are not beginners. Appeasing them may actually go a long way. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make chan

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
stood as a threat. It was actually a joke. I thought that my using of the word "misunderestimate" has made it abundantly clear. Apparently, G.W. doesn't have as many fans as I have previously thought. Once again, it was a joke, I humbly apologize if that was misunderstood. -- Mladen G

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
t;Sorcerer's Apprentice" and my brain still hurts. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performanc

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
ally in memory to the optimizer. There are more obvious fixes to the specific case of temp tables though. I've had a run in with a temporary table, that I had to resolve by disabling hash join and merge join, that really irritated me. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New

[Fwd: Re: [HACKERS] [PERFORM] Slow count(*) again...]

2011-02-02 Thread Mladen Gogala
$rs = $db->Execute($IGEN, array($beg, $end)); show($fmt,$rs); } catch(Exception $e) { The "analyze tempids" line makes my code ugly and slows it down. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vms

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
f access method and used the access method with the highest rank of all available access methods. In practice, it translated into: if an index exists - use it. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Med

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-01 Thread Mladen Gogala
relational masturbation. Trust me. I knew that there is some entertainment value on this list. Samuel, your point of view is very..., er, refreshing. Trust me. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing l

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-01 Thread Mladen Gogala
providing overall performance akin to what the player who has already achieved the world domination. I believe that the company is called "Oracle Corp." or something like that? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The

Re: [PERFORM] Any experience using "shake" defragmenter?

2011-01-30 Thread Mladen Gogala
menter, I'd be grateful for your experience. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Any experience using "shake" defragmenter?

2011-01-30 Thread Mladen Gogala
Mark Felder wrote: Why do you feel the need to defrag your *nix box? Let's stick to the original question and leave my motivation for some other time. Have you used the product? If you have, I'd be happy to hear about your experience with it. -- Mladen Gogala Sr. Oracle

[PERFORM] Any experience using "shake" defragmenter?

2011-01-30 Thread Mladen Gogala
with that? Any positive or negative things to say about shake? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgres

Re: FW: [PERFORM] Queries becoming slow under heavy load

2011-01-28 Thread Mladen Gogala
n the implementation. Vendor supported NAS, running NFS3 or NFS4 should be OK. There are other databases that can use it, too. Some databases even have a built-in NFS client. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integ

Re: [PERFORM] High load,

2011-01-28 Thread Mladen Gogala
Michael Kohl wrote: We are already doing the logging part, we are just a bit behind on the "explain analyze" part of things. One day soon... There is, of course, the auto_explain module which will do that for you. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036

Re: [PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
On 1/27/2011 4:25 PM, Scott Marlowe wrote: On Oracle? Then how can it get the values it needs without having to hit the data store? It can't. It does hit the data store. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via

Re: [PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
LL | EMP |14 | 336 | 3 (0)| 00:00:31 | -- Predicate Information (identified by operation id): --- 3 - filter("EMPNO"=7839) 4 - access("E2".&qu

Re: [PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
On 1/27/2011 3:37 PM, Scott Marlowe wrote: On Thu, Jan 27, 2011 at 1:31 PM, Mladen Gogala wrote: There is INDEX UNIQUE SCAN PK_EMP. Oracle will use an index. That's because Oracle has covering indexes. I am not sure what you mean by "covering indexes" but I hope that for t

Re: [PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
his statement SQL> spool off There is INDEX UNIQUE SCAN PK_EMP. Oracle will use an index. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
hat I tried. Bummer, I will have to copy a large table over. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresq

Re: [PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
(1 row) -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
. Rewriting it as a recursive join is not a problem, but the optimizer doesn't really use the indexes. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make chan

[PERFORM] Postgres 9.0 has a bias against indexes

2011-01-27 Thread Mladen Gogala
y the slowest thing around. I know about the PostgreSQL philosophy which says "hints are bad", and I deeply disagree with it, but would it be possible to have at least one parameter that would change calculations in such a way that indexes are favored, where they exist? -- Mladen Goga

Re: [PERFORM] Real vs Int performance

2011-01-27 Thread Mladen Gogala
tring will probably not make much of a difference. However, if you are calculating sums or averages, there will be a huge difference. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-p

Re: [PERFORM] "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2

2011-01-21 Thread Mladen Gogala
e. I read the function and I don't see anything weird... and it clearly can't be too bad or we would have had more complaints... but... Well the way to test it would be to take the function from 8.3, input the same arguments and see if there is any difference with the results. -- M

Re: [PERFORM] "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2

2011-01-21 Thread Mladen Gogala
ze to 20480MB and see what happens. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to

Re: [PERFORM] copy command and blobs

2011-01-20 Thread Mladen Gogala
generated row id, and is deprecated. You shouldn't be doing anything with it, much less copying it. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance ma

Re: [PERFORM] "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2

2011-01-18 Thread Mladen Gogala
::text) AND ((starttime)::date <= '2007-01-11'::date) AND ((COALESCE(endtime, now()))::date >= '2006-07-15'::date)) -> Hash (cost=630491.54..630491.54 rows=7103 width=23) (actual time=437.307..437.307 rows=12832 loops=1)

Re: [PERFORM] Possible to improve query plan?

2011-01-17 Thread Mladen Gogala
Anything that can be expected for 9.0x? Try writing it with DISTINCT ON instead of a window function, like so: Wouldn't "distinct" necessarily bring about the sort/merge? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com

Re: [PERFORM] "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2

2011-01-17 Thread Mladen Gogala
Achilleas Mantzios wrote: From the whole set of the tests involved, it seems like the "NOT IN" version of the query runs slow in any postgresql 9.0.2 tested. Not only that, it will run slower even using Oracle 11.2 or MySQL 5.5. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway Ne

Re: [PERFORM] The good, old times

2011-01-14 Thread Mladen Gogala
they were *trying* to say? Was it just a joke - 'cos if so, it was kinda flat. -- Craig Ringer -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performa

Re: [PERFORM] queries with lots of UNIONed relations

2011-01-13 Thread Mladen Gogala
algorithms that have been paralleled for a long time are precisely sort/merge and hash algorithms used for union and group by functions. This is what I have in mind: http://labs.google.com/papers/mapreduce.html -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.v

[PERFORM] The good, old times

2011-01-12 Thread Mladen Gogala
I am running a postgres update on one of my machines: Downloading Packages: (1/7): postgresql90-plpython-9.0.2-2PGDG.rhel5.x86_64.rp | 50 kB 00:02 (2/7): postgresql90-plperl-9.0.2-2PGDG.rhel5.x86_64.rpm | 51 kB 00:03 (3/7): postgresql90-libs-9.0.2-2PGDG.rhel5.x86_64.rpm

Re: [PERFORM] "SELECT .. WHERE NOT IN" query running for hours

2011-01-10 Thread Mladen Gogala
le the !EXISTS is just a complement of join. It's all in the basic set theory which serves as a model for the relational databases. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutio

Re: [PERFORM] "SELECT .. WHERE NOT IN" query running for hours

2011-01-06 Thread Mladen Gogala
've seen that in Oracle applications, MS SQL applications and, of course MySQL applications. Optimizing queries is far from trivial. Μλαδεν Γογαλα -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-p

Re: [PERFORM] CPU bound

2011-01-03 Thread Mladen Gogala
Jim Nasby wrote: On Dec 20, 2010, at 12:47 AM, Mladen Gogala wrote: Good time accounting is the most compelling reason for having a wait event interface, like Oracle. Without the wait event interface, one cannot really tell where the time is spent, at least not without profiling the

Re: [PERFORM] long wait times in ProcessCatchupEvent()

2010-12-29 Thread Mladen Gogala
;s problem and your description but I wasn't able to figure out what is sinval lock and what does it lock? I apologize if the question is stupid. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailin

Re: [PERFORM] concurrent IO in postgres?

2010-12-25 Thread Mladen Gogala
Jeff Janes wrote: If the background writer cannot keep up, then the individual backends start doing writes as well, so it isn't really serialized.. Is there any parameter governing that behavior? Can you tell me where in the code (version 9.0.2) can I find that? Thanks. -- Mladen G

Re: [PERFORM] Performance of PostgreSQL over NFS

2010-12-21 Thread Mladen Gogala
sure about PostgreSQL. Did anybody try that? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make ch

[PERFORM] Performance of PostgreSQL over NFS

2010-12-21 Thread Mladen Gogala
I was asked about performance of PostgreSQL on NetApp, the protocol should be NFSv3. Has anybody tried it? The database in question is a DW type, a bunch of documents indexed by Sphinx. Does anyone have any information? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212

Re: [PERFORM] CPU bound

2010-12-21 Thread Mladen Gogala
hings like waiting on I/O or waiting on lock, that would be extremely useful. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:

Re: [PERFORM] CPU bound

2010-12-19 Thread Mladen Gogala
ason for having a wait event interface, like Oracle. Without the wait event interface, one cannot really tell where the time is spent, at least not without profiling the database code, which is not an option for a production database. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, N

Re: [PERFORM] Index Bloat - how to tell?

2010-12-17 Thread Mladen Gogala
and will be able to provide a reasonable explanation. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Index Bloat - how to tell?

2010-12-16 Thread Mladen Gogala
| avg_leaf_density | leaf_fragmentation -+++---+++-+---+--+--- - 2 | 1 | 647168 | 3 | 0 | 78 | 0 | 0 |89.67 |

Re: [PERFORM] Index Bloat - how to tell?

2010-12-14 Thread Mladen Gogala
you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

Re: [PERFORM] Compared MS SQL 2000 to Postgresql 9.0 on Windows

2010-12-07 Thread Mladen Gogala
Postgres server is s much slower on the joins? I am trying to understand what is going on here so please don’t flame me. Any advice is appreciated. Are all structures the same? Are all indexes the same? What does "explain analyze" tell you? -- Mladen Gogala Sr. Oracle

Re: [PERFORM] Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT

2010-12-04 Thread Mladen Gogala
s? It would be 120 partitions. Can you please elaborate on that limitation? Any plans on lifting that restriction? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To

Re: [PERFORM] Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT

2010-12-04 Thread Mladen Gogala
experience, planner doesn't do a very good job with partitions, especially with things like "min" or "max" which should not be resolved by a full table scan, if there are indexes on partitions. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5

Re: [PERFORM] SELECT INTO large FKyed table is slow

2010-12-01 Thread Mladen Gogala
Kevin Grittner wrote: Mladen Gogala wrote: Been there, done that. Not only was performance quite poor compared to Linux, but reliability and staff time to manage things suffered in comparison to Linux. I must say that I am quite impressed with Windows 7 servers, especially 64 bit

Re: [PERFORM] SELECT INTO large FKyed table is slow

2010-12-01 Thread Mladen Gogala
PostgreSQL 15.0. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] SELECT INTO large FKyed table is slow

2010-12-01 Thread Mladen Gogala
-of-xfs-on-linux.html There is a operating system which comes with a very decent extent based file system and a defragmentation tool, included in the OS. The file system is called "NTFS" and company is in the land of Redmond, WA where the shadows lie. One OS to rule them all... -- Mladen Go

Re: [PERFORM] Clarification, please

2010-12-01 Thread Mladen Gogala
Richard Broersma wrote: It looks like the check isn't preformed until COMMIT. So, the index is not actually updated until commit? H, that seems unlikely. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Lead

[PERFORM] Clarification, please

2010-12-01 Thread Mladen Gogala
ice into a UNIQUE index? What's going on here? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgre

Re: [PERFORM] SELECT INTO large FKyed table is slow

2010-12-01 Thread Mladen Gogala
Mario Splivalo wrote: Yes, as Mladen Gogala had advised. No noticable change in performance - it's still slow :) Declaring constraints as deferrable  doesn't do anything as such, you have to actually set the constraints deferred to have an effect. You have to do i

Re: [PERFORM] SELECT INTO large FKyed table is slow

2010-11-30 Thread Mladen Gogala
s - is there anything I can do to make INSERTS with PK faster? Or, since all the reference checking is done inside the procedure for loading data, shall I abandon those constraints entirely? Mario -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-525

Re: [PERFORM] Query Performance SQL Server vs. Postgresql

2010-11-17 Thread Mladen Gogala
I thought that I've seen an announcement about the SQL Server for Linux on 04/01/2005? I cannot find the link right now, but I am quite certain that there was such an announcement. From: pgsql-performance-ow...@postgresql.org To: Tomas Vondra Cc: pgsql-perform

Re: [PERFORM] Defaulting wal_sync_method to fdatasync on Linux for 9.1?

2010-11-16 Thread Mladen Gogala
that's the right approach, or if we should just increase the default value for wal_buffers to something more reasonable. We'd love to, but wal_buffers uses sysV shmem. Speaking of the SYSV SHMEM, is it possible to use huge pages? -- Mladen Gogala Sr. Oracle DBA 1500 Broadwa

Re: [PERFORM] MVCC performance issue

2010-11-14 Thread Mladen Gogala
the fact that there is no row id, so that the table header and the indexes need to be updated much more frequently than is the case with Oracle. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing lis

Re: [PERFORM] MVCC performance issue

2010-11-13 Thread Mladen Gogala
n, Oracle restarts the entire transaction, but neither MVCC mechanism would allow for the silly ATM example described in the blog. Both databases would have noticed change in the balance, both databases would have ended with the proper balance in the account. -- Mladen Gogala Sr. Orac

Re: [PERFORM] anti-join chosen even when slower than old plan

2010-11-11 Thread Mladen Gogala
pying a page or two from the Oracle's book, looks like a good idea to me. The only thing I dislike about Oracle is its price, not its complexity. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media In

Re: [PERFORM] anti-join chosen even when slower than old plan

2010-11-11 Thread Mladen Gogala
Kevin Grittner wrote: Mladen Gogala wrote: create a definitive bias toward one type of the execution plan. We're talking about trying to support the exact opposite. I understand this, that is precisely the reason for my intervention into the discussion of experts, which I a

Re: [PERFORM] anti-join chosen even when slower than old plan

2010-11-11 Thread Mladen Gogala
not the only concern. Running applications on the system usually requires plan stability. Means of external control of the execution plan, DBA knobs and buttons that can be turned and pushed to produce the desired plan are also very much desired. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New

Re: [PERFORM] anti-join chosen even when slower than old plan

2010-11-10 Thread Mladen Gogala
confess that the idea about such parameter is not entirely mine:*http://tinyurl.com/33gu4f6* -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com

[PERFORM] Array interface

2010-11-08 Thread Mladen Gogala
cuted $exec_cnt times.\n"; } The variable "$sth" is a prepared statement handle for the insert statement. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sen

[PERFORM] Array interface

2010-11-08 Thread Mladen Gogala
cuted $exec_cnt times.\n"; } The variable "$sth" is a prepared statement handle. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance

Re: [PERFORM] Running PostgreSQL as fast as possible no matter the consequences

2010-11-05 Thread Mladen Gogala
ramdisk, if you have enough RAM. It will fast, really. That is approximately the same thing as the answer to the question whether Ford Taurus can reach 200mph. It can, just once, if you run it down the cliff. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http

[PERFORM] Bufer cache replacement LRU algorithm?

2010-11-03 Thread Mladen Gogala
Where can I find the documentation describing the buffer replacement policy? Are there any parameters governing the page replacement policy? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence

Re: [PERFORM] Array interface

2010-11-03 Thread Mladen Gogala
e try pastebin if you're having email censorship issues. -Conor I posted it to comp.databases.postgresql. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent

[PERFORM] Array interface

2010-11-02 Thread Mladen Gogala
cted array bind to produce better results over the network than the row-by-row operations, yet it didn't. Can anybody elaborate a bit? It seems that some kind of email scanner has quarantined my emails containing Perl code samples as dangerous, so I can't really show the code sample

[PERFORM] Test

2010-11-02 Thread Mladen Gogala
Can you hear me now? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Mladen Gogala
On 10/28/2010 10:53 AM, Richard Broersma wrote: On Thu, Oct 28, 2010 at 7:51 AM, Mladen Gogala wrote: Yyesss! Any time frame on that? Can you make it into 9.0.2? Maybe 9.1.0 or 9.2.0 :) 9.0's features are already frozen. Well, with all this global warming around us, index scans may

Re: [PERFORM] Slow Query- Simple taking

2010-10-28 Thread Mladen Gogala
! Any time frame on that? Can you make it into 9.0.2? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To ma

Re: [PERFORM] Postgres insert performance and storage requirement compared to Oracle

2010-10-27 Thread Mladen Gogala
r idea and/or required. Especially in postgres, with no undo-log, bulk inserts in one large transaction work out very well -- usually better than multiple smaller transactions. I don't contest that. I also prefer to do things in one big transaction, if possible. -- Mladen Gogala Sr.

Re: [PERFORM] temporary tables, indexes, and query plans

2010-10-27 Thread Mladen Gogala
target? The default is rather small, it doesn't produce very good or usable histograms. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing li

Re: [PERFORM] Postgres insert performance and storage requirement compared to Oracle

2010-10-26 Thread Mladen Gogala
oting ducks in a duck pond, with a howitzer. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Postgres insert performance and storage requirement compared to Oracle

2010-10-26 Thread Mladen Gogala
re fragile approach so weigh the pros/cons carefully. merlin Truncate temporary table? What a horrible advice! All that you need is the temporary table to delete rows on commit. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in

Re: [PERFORM] which one is faster

2010-10-26 Thread Mladen Gogala
timizer will generate the sequential scan in both cases. In other words, PostgreSQL will read the entire table when counting, no matter what. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performanc

Re: [PERFORM] Postgres insert performance and storage requirement compared to Oracle

2010-10-25 Thread Mladen Gogala
have done some tests but results for PostgreSQL have not been > encouraging for a few of them. Tell us more about your tests and results please. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence

Re: [PERFORM] Periodically slow inserts

2010-10-21 Thread Mladen Gogala
e is spent? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscrip

Re: [PERFORM] Index scan is not working, why??

2010-10-21 Thread Mladen Gogala
= 'Call'::text) OR ((acttype)::text = 'Task'::text)) Total runtime: 732.956 ms (3 rows) Al, what percentage of the rows fits the above criteria? How big are your histograms? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com

Re: [PERFORM] What is postmaster doing?

2010-10-20 Thread Mladen Gogala
/auto-explain.html For the log files, you can parse them using pgfouine and quickly find out the most expensive SQL statements. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions --

Re: [PERFORM] HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?

2010-10-19 Thread Mladen Gogala
n the other way around? May I ask a stupid question: how is the query cost calculated? What are the units? I/O requests? CPU cycles? Monopoly money? -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelli

Re: [PERFORM] Help with duration of statement: EXECUTE [PREPARE: COMMIT]

2010-10-18 Thread Mladen Gogala
Tom Lane wrote: My guess would be overstressed disk subsystem. A COMMIT doesn't require much except fsync'ing the commit WAL record down to disk ... Doesn't the "commit" statement also release all the locks held by the transaction? -- Mladen Gogala Sr. Oracle DB

Re: [PERFORM] Select count(*), the sequel

2010-10-18 Thread Mladen Gogala
Best regards, Vitalii Tymchyshyn Vitalli, yes I did vacuum before the count. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:

[PERFORM] Select count(*), the sequel

2010-10-17 Thread Mladen Gogala
There was some doubt as for the speed of doing the select count(*) in PostgreSQL and Oracle. To that end, I copied the most part of the Oracle table I used before to Postgres. Although the copy wasn't complete, the resulting table is already significantly larger than the table it was copied from

[PERFORM] Select count(*), the sequel

2010-10-16 Thread Mladen Gogala
inux Server release 5.5 (Tikanga) [mgog...@lpo-postgres-d01 ~]$ Linux lpo-postgres-d01 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [mgog...@lpo-postgres-d01 ~]$ -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com The Leader in integrated Media Intelligence Solutions

  1   2   >