= 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
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
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
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
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
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
_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
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
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
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
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
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);
>>
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
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
> > -
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
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
16 matches
Mail list logo