[PERFORM] Intersect/Union X AND/OR
Hi all, I found this presentation from B. Momjian: http://momjian.us/main/writings/pgsql/performance.pdf I'm interested in what he said about " Intersect/Union X AND/OR " , Can I find a transcription or a video of this presentation? Can anyone explain it to me? Thanks, Thiago Godoi
Re: [PERFORM] Intersect/Union X AND/OR
Thiago Godoi wrote: > Hi all, > > I found this presentation from B. Momjian: > > http://momjian.us/main/writings/pgsql/performance.pdf > > I'm interested in what he said about " Intersect/Union X AND/OR " , Can I > find a transcription or a video of this presentation? Can anyone explain it > to me? Well, there is a recording of the webcast on the EnterpriseDB web site, but I am afraid they only allow viewing of 3+ hour webcasts by EnterpriseDB customers. The idea is that a query that uses an OR can be rewritten as two SELECTs with a UNION between them. I have seen rare cases where this is a win, so I mentioned it in that talk. Intersection is similarly possible for AND in WHERE clauses. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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] Intersect/Union X AND/OR
On Fri, Dec 2, 2011 at 1:49 PM, Bruce Momjian wrote: > Thiago Godoi wrote: >> Hi all, >> >> I found this presentation from B. Momjian: >> >> http://momjian.us/main/writings/pgsql/performance.pdf >> >> I'm interested in what he said about " Intersect/Union X AND/OR " , Can I >> find a transcription or a video of this presentation? Can anyone explain it >> to me? > > Well, there is a recording of the webcast on the EnterpriseDB web site, > but I am afraid they only allow viewing of 3+ hour webcasts by > EnterpriseDB customers. > > The idea is that a query that uses an OR can be rewritten as two SELECTs > with a UNION between them. I have seen rare cases where this is a win, > so I mentioned it in that talk. Intersection is similarly possible for > AND in WHERE clauses. I've seen this as well. Also boolean set EXCEPT is useful as well in the occasional oddball case. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] Question about VACUUM
Hi friends I want to know if it's possible to predict (calculate), how long a VACUUM FULL process will consume in a table? can I apply some formula to calculate this? thanks -- -- Visita : http://www.eqsoft.net -- Sigueme en Twitter : http://www.twitter.com/ernestoq -- 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] Question about VACUUM
On Fri, Dec 2, 2011 at 8:32 PM, Ernesto Quiñones wrote: > Hi friends > > I want to know if it's possible to predict (calculate), how long a > VACUUM FULL process will consume in a table? > > can I apply some formula to calculate this? If you look at what iostat is doing while the vacuum full is running, and divide the size of the table by that k/sec you can get a good approximation of how long it will take. Do you have naptime set to anything above 0? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] pg_upgrade
So we are making progress on our performance issues, we are splitting the data, changing the index value etc. So far having some success, but we also want to test out some of the options and changes in the 9 branch, but trying to dump and restore 750gb of data is not all that fun, so I'm trying to avoid that. So upgraded from 8.4.4 64 bit to 9.1.1 64bit. If we upgrade a database that just uses the public table space there are no issues, works fine. However when we try to upgrade a db that has tablespaces defined it errors out trying to load the data from the then now new db. The tablespaces are hardcoded with a path, so that seems to cause issues. Steps I'm taking Standard location of data /data/db Standard binary location /pgsql/bin I'm moving the standard location to /data1/db and moving the binaries to /pgsql8/bin WHY: because my build scripts put my binaries and data in these locations, so without recreating my build process, I have to move the current data and binary locations before I install 9.11 So I move olddata to /data1/db oldbinary to /pgsql8/bin new 9.1.1 db goes to /data/db newbinary installs at /pgsql/ So when I run pg_upgrade (check validates the config), however trying to the upgrade nets; Restoring user relation files /data/queue/16384/16406 error while copying queue.adm_version (/data/queue/16384/16406 to /data/queue/PG_9.1_201105231/16407/16406): No such file or directory Failure, exiting As you can see, it's sticking with it's original path and not realizing that I'm trying now to install into /data from /data1 What is the flaw here? Do I have to rebuild my build process to install in a different location?, not sure what my choices are here. I mean I'm telling the upgrade process where new and old are located, I believe it should be overriding something and not allowing the included error. Slaps and or pointers are welcome Tory -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
