Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Miernik <[EMAIL PROTECTED]> wrote: > I present a SELECT uid plan with the 1000 table also below, just to be > sure, this is the "bad" plan, that takes forever: > > miernik=> EXPLAIN SELECT uid FROM cnts WHERE uid IN (SELECT uid FROM alog

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Miernik <[EMAIL PROTECTED]> wrote: > Something goes wrong that this query plan thinks there is only gonna be > 1 row from (SELECT uid FROM alog ... ) so chooses such query plan, and > thus it runs forever (at least so long that I didn't bother to wait, > like 10 minutes): &g

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

On Sat, Aug 09, 2008 at 05:37:29PM -0400, Tom Lane wrote: > > miernik=> explain select * from cnts, alog where alog.uid = cnts.uid; > >QUERY PLAN > > -

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Miernik <[EMAIL PROTECTED]> wrote: > How can I bring it back to working? Like un-run ANALYZE on that table or > something? All was running reasonably well before I changed from > autovacuum to running ANALYZE manually, and I thought I would improve > performance... ;( I now

Re: [PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Tom Lane <[EMAIL PROTECTED]> wrote: > Miernik <[EMAIL PROTECTED]> writes: >> miernik=> EXPLAIN UPDATE cnts SET p0 = FALSE WHERE uid IN (SELECT uid FROM >> alog WHERE pid = 3452654 AND o = 1); >>

[PERFORM] why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?

Something goes wrong that this query plan thinks there is only gonna be 1 row from (SELECT uid FROM alog ... ) so chooses such query plan, and thus it runs forever (at least so long that I didn't bother to wait, like 10 minutes): miernik=> EXPLAIN UPDATE cnts SET p0 = FALSE WHERE uid IN

Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence

link to `../share/postgresql-common/pg_wrapper' [EMAIL PROTECTED]:~$ file /usr/share/postgresql-common/pg_wrapper /usr/share/postgresql-common/pg_wrapper: a /usr/bin/perl -w script text executable [EMAIL PROTECTED]:~$ -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing

Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence

some count(*) stuff, it now does things in about one second, which took a few minutes to finish before (if the other part of the scripts where doing something else on the database at the same time). -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performanc

Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence

l at least be a "cleaner" implementation. In /etc/pgpool.conf I used: # number of pre-forked child process num_init_children = 1 # Number of connection pools allowed for a child process max_pool = 1 Wanted to install pgbouncer, but it is broken currently in Debian. And why is it in contr

Re: [PERFORM] why "WHERE uid NOT IN" is so slow, and EXCEPT in the same situtation is fast?

_the _result, some_other_column_also). If any "uid" column of any row would have been NULL, it wouldn't appear in that INNER JOIN, no? -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] why "WHERE uid NOT IN" is so slow, and EXCEPT in the same situtation is fast?

Two queries which do the same thing, first one takes ages to complete (did wait several minutes and cancelled it), while the second one took 9 seconds? Don't they do the same thing? miernik=> EXPLAIN SELECT uid FROM locks WHERE uid NOT IN (SELECT uid FROM locks INNER JOIN wys USING (ui

[PERFORM] what is less resource-intensive, WHERE id IN or INNER JOIN?

one should be faster, less resource intensive, use less RAM, disk access, etc? Are there any other even better ways to acomlish the same query? Using 8.3.3 on a 48 MB RAM Xen. -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Database size Vs performance degradation

to just DROP the table every hour, and recreate it, then to TRUNCATE it? Or does TRUNCATE take care of the boat as good as a DROP and CREATE? I am running 8.3.3 in a 48 MB RAM Xen, so performance matters much. -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-p

Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence

rms of performance. Oh here is something more: http://vpsempire.com/action.php?do=vpslite 256 MB for 7.45$ per month 512 MB for 11.95$ per month however it doesn't say what is the virtualization software, so don't really know what it is. -- Miernik http://miernik.name/ -- Sent

Re: [PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence

dumped. If I could shorten the time it takes to run each query by a factor of 3 that's something worth going for. -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] how to fix problem then when two queries run at the same time, it takes longer to complete then if run in sequence

= 5MB work_mem = 1024kB are these good values, or could perhaps changing something improve it a bit? Any other parameters to look at? -- Miernik http://miernik.name/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http