On Tue, 2003-11-04 at 09:49, [EMAIL PROTECTED] wrote:
> How do we measure the response time in postgresql?
In addition to EXPLAIN ANALYZE, the log_min_duration_statement
configuration variable and the \timing psql command might also be
useful.
-Neil
---(end of broadcast
<[EMAIL PROTECTED]> writes:
> The \timing psql command gives different time for the same query executed
> repeatedly.
That's probably because executing the query repeatedly results in
different execution times, as one would expect. \timing returns the
"exact" query response time, nevertheless.
-N
"Patrick Hatcher" <[EMAIL PROTECTED]> writes:
> Do you have an index on ts.bytes? Josh had suggested this and after I put
> it on my summed fields, I saw a speed increase.
What's the reasoning behind this? ISTM that sum() should never use an
index, nor would it benefit from using one.
-Neil
--
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> -> Index Scan using tl_month on traffic_logs ts (cost=0.00..30763.02 rows=8213
> width=16) (actual time=0.29..5562.25 rows=462198 loops=1)
> Index Cond: (month_trunc(runtime) = '2003-10-01 00:00:00'::timestamp without
> time zone)
Interest
Suchandra Thapa <[EMAIL PROTECTED]> writes:
> I was thinking using about using a raid 1+0 array to hold the
> database but since I can use different array types, would it be
> better to use 1+0 for the wal logs and a raid 5 for the database?
It has been recommended on this list that getting a RAID
Josh Berkus <[EMAIL PROTECTED]> writes:
> The only thing you're adding to the query is a second SORT step, so it
> shouldn't require any more time/memory than the query's first SORT
> did.
Interesting -- I wonder if it would be possible for the optimizer to
detect this and avoid the redundant inn
Tom Lane <[EMAIL PROTECTED]> writes:
> (I believe the previous discussion also agreed that we wanted to
> postpone the freezing of now(), which currently also happens at
> BEGIN rather than the first command after BEGIN.)
That doesn't make sense to me: from a user's perspective, the "start
of the
Torsten Schulz <[EMAIL PROTECTED]> writes:
> Our Server:
> Dual-CPU with 1.2 GHz
> 1.5 GB RAM
What kind of I/O subsystem is in this machine? This is an x86 machine,
right?
> Has anyone an idea what's the best configuration for thta server?
It is difficult to say until you provide some informatio
<[EMAIL PROTECTED]> writes:
> But it was not this bad in 7.3 as far as i understand.
No, I believe this behavior is present in any recent release of
PostgreSQL.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send a
Stefan Champailler <[EMAIL PROTECTED]> writes:
> So here's my trouble : some DELETE statement take up to 1 minute to
> complete (but not always, sometimes it's fast, sometimes it's that
> slow). Here's a typical one : DELETE FROM response_bool WHERE
> response_id = '125' The response_bool table has
LIANHE SHAO <[EMAIL PROTECTED]> writes:
> We will have a very large database to store microarray data (may
> exceed 80-100G some day). now we have 1G RAM, 2G Hz Pentium 4, 1
> CPU. and enough hard disk.
> Could anybody tell me that our hardware is an issue or not?
IMHO the size of the DB is less
Josh Berkus <[EMAIL PROTECTED]> writes:
> 1) to keep it working, you will probably need to run ANALZYE more
>often than you have been;
I'm not sure why this would be the case -- can you elaborate?
> 4) Currently, pg_dump does *not* back up statistics settings.
Yes, it does.
-Neil
Josh Berkus <[EMAIL PROTECTED]> writes:
> Oh, good. Was this a 7.4 improvement?
No, it was in 7.3
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Steve Wampler <[EMAIL PROTECTED]> writes:
> PG: 7.2.3 (RedHat 8.0)
You're using PG 7.2.3 with the PG 7.1 JDBC driver; FWIW, upgrading to
newer software is highly recommended.
> The two sites were performing at comparable speeds until a few days
> ago, when we deleted several million records from
LIANHE SHAO <[EMAIL PROTECTED]> writes:
> Hello, I use php as front-end to query our database. When I use
> System Monitor to check the usage of cpu and memory, I noticed that
> the cpu very easily gets up to 100%. Is that normal? if not, could
> someone points out possible reason?
You haven't giv
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> This is not a bug. It is just that people find it confusing when
> postgresql planner consider seemingly same type as different.
It certainly is a bug, or at least a deficiency: PostgreSQL planner
*could* use the index to process the query, but the
stephen farrell <[EMAIL PROTECTED]> writes:
> With the indexes created it worked. It took about 4 hours, but it
> inserted all of the records.
Has this been satisfactorily resolved?
If not, can you post an EXPLAIN ANALYZE for the failing query, as Tom
asked earlier?
-Neil
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Note : The Pgbench runs were conducted using -s 10 and -t 1000 -c
> 1->64, 2 - 3 runs of each setup were performed (averaged figures
> shown).
FYI, the pgbench docs state:
NOTE: scaling factor should be at least as large as the largest
numbe
Sai Hertz And Control Systems <[EMAIL PROTECTED]> writes:
> I have created my tables without OIDS now my doubts are :
> 1. Will this speed up the data insertion process
Slightly. It means that each inserted row will be 4 bytes smaller (on
disk), which in turn means you can fit more tuples on a p
Tom Lane <[EMAIL PROTECTED]> writes:
> I don't believe anyone has proposed removing the facility
> altogether. There's a big difference between making the default
> behavior be not to have OIDs and removing the ability to have OIDs.
Right, that's what I had meant to say. Sorry for the inaccuracy.
"Sean P. Thomas" <[EMAIL PROTECTED]> writes:
> 1. Is there any performance difference for declaring a primary or
> foreign key a column or table contraint? From the documentation,
> which way is faster and/or scales better:
>
> CREATE TABLE distributors (
> did integer,
> namev
"David Shadovitz" <[EMAIL PROTECTED]> writes:
> I'm running PG 7.2.2 on RH Linux 8.0.
Note that this version of PostgreSQL is quite old.
> I'd like to know why "VACUUM ANALYZE " is extemely slow (hours) for
> certain tables.
Is there another concurrent transaction that has modified the table
bu
David Shadovitz <[EMAIL PROTECTED]> writes:
> What could account for this difference?
Lots of things -- disk fragmentation, expired tuples that aren't being
cleaned up by VACUUM due to a long-lived transaction, the state of the
kernel buffer cache, the configuration of the kernel, etc.
> How can
John Siracusa <[EMAIL PROTECTED]> writes:
> 1. The query "select max(foo) from bar" where the column foo has an index.
> Aren't indexes ordered? If not, an "ordered index" would be useful in this
> situation so that this query, rather than doing a sequential scan of the
> whole table, would just "
"scott.marlowe" <[EMAIL PROTECTED]> writes:
> Yes, previously run query should be faster, if it fits in kernel
> cache.
Or the PostgreSQL buffer cache.
> Plus, the design of Postgresql is such that it would have to do a
> LOT of cache checking to see if there were any updates to the
> underlying
Harald Fuchs <[EMAIL PROTECTED]> writes:
> Does anyone know how to access the affected values for
> statement-level triggers? I mean what the "old" and "new"
> pseudo-records are for row-level triggers.
Yeah, I didn't get around to implementing that. If anyone wants this
feature, I'd encourage th
Richard Huxton <[EMAIL PROTECTED]> writes:
> I didn't think they'd be meaningful for a statement-level
> trigger. Surely OLD/NEW are by definition row-level details.
Granted; the feature in question is *some* means of accessing the
result set of a statement-level trigger -- it probably would not u
"Loeke" <[EMAIL PROTECTED]> writes:
> do views exist fysically a separate "table", or are they generated
> on the fly whenever they are queried?
Views are implementing by rewriting queries into the appropriate query
on the view's base tables.
http://www.postgresql.org/docs/current/static/rules-vi
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> Right now, it is hotly debated on HACKERS about adding a NOWAIT
> clause to SELECT FOR UPDATE. If you think your application
> deployment is away for months and can try CVS head, you can expect
> some action on it in coming few days.
You can also t
Simon Riggs wrote:
Josh Berkus wrote
Simon Riggs wrote
Please set WAL_DEBUG to 1 so we can see a bit more info: thanks.
I'm pretty sure that WAL_DEBUG requires a compile-time option.
I'm surprised, but you are right, the manual does SAY this requires a
compile time option; it is unfortunately not
Josh Berkus wrote:
Hmmm. I was told that it was this way for 7.4 as well; that's why it's in
the docs that way.
No such statement is made in the docs AFAIK: they merely say "If
nonzero, turn on WAL-related debugging output."
I invented a new #ifdef symbol when making this change in CVS HEAD, s
Simon Riggs wrote:
On the other hand, I was just about to change the wal_debug behaviour to
allow better debugging of PITR features as they're added.
That's a development activity. Enabling the WAL_DEBUG #ifdef by
default during the 7.5 development cycle would be uncontroversial, I
think.
I thin
Mike Nolan wrote:
Is there a way to copy a table INCLUDING the check constraints? If not,
then that information is lost, unlike varchar(n).
"pg_dump -t" should work fine, unless I'm misunderstanding you.
-Neil
---(end of broadcast)---
TIP 5: Have y
Steven Butler wrote:
I've recently converted a database to use bigint for the indices. Suddenly
simple queries like
select * from new_test_result where parent_id = 2
are doing full table scans instead of using the index.
This is fixed in CVS HEAD. In the mean time, you can enclose the
integer li
Andrew Sullivan wrote:
"Intended", no. "Expected", yes. This topic has had the best
Postgres minds work on it, and so far nobody's come up with a
solution.
Actually, this has already been fixed in CVS HEAD (as I mentioned in
this thread yesterday). To wit:
nconway=# create table t1 (a int8);
CR
101 - 135 of 135 matches
Mail list logo
