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

Please, don't include me on your emails. I unsubscribed from the list. Cédric Villemain wrote: 2011/2/4 Frank Heikens frankheik...@mac.com: On 04 Feb, 2011,at 02:56 PM, Mladen Gogala mladen.gog...@vmsinfo.com wrote: Віталій Тимчишин wrote: Hi, all. All this optimizer vs hint thread

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

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 (212) 329-5251

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

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, has

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

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 expense

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

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 Media

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

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't cover

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

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 Integrated

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

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 via pgsql-performance mailing list (pgsql

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

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-performance mailing list (pgsql

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

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...

, in the form of enable_method 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-performance mailing list (pgsql-performance@postgresql.org) To make

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

-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@postgresql.org

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

have in mind that hints are already here, in the form of enable_method 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 1500 Broadway New York, NY 10036 (212) 329-5251

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

Kevin Grittner wrote: Mladen Gogala mladen.gog...@vmsinfo.com 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

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

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 the opposite. Database whose

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

Robert Haas wrote: On Thu, Feb 3, 2011 at 6:33 PM, Mladen Gogala mladen.gog...@vmsinfo.com wrote: Kevin Grittner wrote: Mladen Gogala mladen.gog...@vmsinfo.com wrote: Maybe we can agree to remove that ridiculous we don't want hints note from Postgresql wiki? I'd

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

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 Media Intelligence

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

Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media

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

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 York, NY 10036 (212) 329-5251 http://www.vmsinfo.com

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

. 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 Gogala Sr. Oracle DBA 1500 Broadway New

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

. 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 changes to your subscription: http

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

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 Leader in Integrated Media

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

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 list (pgsql

[PERFORM] Any experience using shake defragmenter?

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.postgresql.org/mailpref/pgsql

Re: [PERFORM] Any experience using shake defragmenter?

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 DBA 1500

Re: [PERFORM] Any experience using shake defragmenter?

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] High load,

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 (212) 329

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

on 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 Integrated

Re: [PERFORM] Real vs Int performance

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-performance

[PERFORM] Postgres 9.0 has a bias against indexes

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 Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com -- Sent via pgsql-performance

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

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 changes to your subscription: http

Re: [PERFORM] Postgres 9.0 has a bias against 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 changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

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

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.postgresql.org

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

): --- 4 - access(EMPNO=7839) 5 - access(EMP.MGR=E.EMPNO) Note - - SQL plan baseline SQL_PLAN_1tmxjj25531vff51d791e used for this statement SQL spool off There is INDEX UNIQUE SCAN PK_EMP. Oracle will use an index. -- Mladen Gogala

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

On 1/27/2011 3:37 PM, Scott Marlowe wrote: On Thu, Jan 27, 2011 at 1:31 PM, Mladen Gogala mladen.gog...@vmsinfo.com 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

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

| -- Predicate Information (identified by operation id): --- 3 - filter(EMPNO=7839) 4 - access(E2.MGR=E1.EMPNO) SQL spool off -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251

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

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 pgsql

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

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 your

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

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. -- Mladen Gogala Sr

Re: [PERFORM] copy command and blobs

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 mailing

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

and the filtering conditions look differently. Are you sure that the plans are from the same query? -- 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

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

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 New York, NY

Re: [PERFORM] Possible to improve query plan?

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 The Leader in Integrated Media Intelligence

Re: [PERFORM] The good, old times

? 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-performance mailing list (pgsql-performance

Re: [PERFORM] queries with lots of UNIONed relations

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.vmsinfo.com

[PERFORM] The good, old times

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

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 Solutions -- Sent via pgsql-performance mailing list (pgsql

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

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-performance@postgresql.org) To make changes to your

Re: [PERFORM] CPU bound

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

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

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 mailing list (pgsql-performance@postgresql.org

Re: [PERFORM] concurrent IO in postgres?

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 Gogala

Re: [PERFORM] CPU bound

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: http

[PERFORM] Performance of PostgreSQL over NFS

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] Performance of PostgreSQL over NFS

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 changes

Re: [PERFORM] CPU bound

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, NY 10036 (212) 329

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

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?

-+++---+++-+---+--+--- - 2 | 1 | 647168 | 3 | 0 | 78 | 0 | 0 |89.67 | 0 (1 row) -- Mladen Gogala

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

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. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader

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

, 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-5251 www.vmsinfo.com -- Sent via pgsql

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

? 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 make

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

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 it within

[PERFORM] Clarification, 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 Solutions -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] Clarification, please

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 Leader

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

-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 Gogala Sr. Oracle DBA

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

with 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

Kevin Grittner wrote: Mladen Gogala mladen.gog...@vmsinfo.com 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

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

entirely? Mario -- 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] Query Performance SQL Server vs. Postgresql

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

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

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 Broadway New York, NY 10036

Re: [PERFORM] MVCC performance issue

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 list (pgsql-performance

Re: [PERFORM] MVCC performance issue

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. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com

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

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 York, NY 10036 (212) 329-5251

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

Kevin Grittner wrote: Mladen Gogala mladen.gog...@vmsinfo.com 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

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

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 Intelligence Solutions

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

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

. -- 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://www.postgresql.org

[PERFORM] Array interface

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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription

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

to 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

Re: [PERFORM] Array interface

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 via pgsql

[PERFORM] Test

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

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 make changes

Re: [PERFORM] Slow Query- Simple taking

On 10/28/2010 10:53 AM, Richard Broersma wrote: On Thu, Oct 28, 2010 at 7:51 AM, Mladen Gogala mladen.gog...@vmsinfo.com 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

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

, 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 list (pgsql-performance@postgresql.org

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

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. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader

Re: [PERFORM] which one is faster

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-performance@postgresql.org) To make changes

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

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 Integrated

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

. -- 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] Postgres insert performance and storage requirement compared to Oracle

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 Solutions

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

'::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 -- Sent via pgsql-performance mailing list (pgsql-performance

Re: [PERFORM] Periodically slow inserts

? -- 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] What is postmaster doing?

-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 -- Sent

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

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 Intelligence

[PERFORM] Select count(*), the sequel

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

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

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: http

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

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 DBA 1500 Broadway New York, NY

[PERFORM] Select count(*), the sequel

: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

Re: [PERFORM] oracle to psql migration - slow query in postgres

Samuel Gendler wrote: On Thu, Oct 14, 2010 at 8:59 PM, Mladen Gogala mladen.gog...@vmsinfo.com mailto:mladen.gog...@vmsinfo.com wrote: If working with partitioning, be very aware that PostgreSQL optimizer has certain problems with partitions, especially with group functions

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

command. AFAIK, Postgres doesn't have anything like that. Oracle uses raw devices precisely to avoid double buffering. -- 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

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

(*) to establish existence is bad for performance and for code readability. -- 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

Re: [PERFORM] Bogus startup cost for WindowAgg

easily guess the distribution of values. -- 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

  1   2   >