Here's an oddity. I have 10 databases, each with about a dozen connections to Postgres
(about 120 connections total), and at midnight they're all idle. These are mod_perl
programs (like a FastCGI -- they stay connected so they're ready for instant service).
So using ps -ef and grep, we find
Gregory Stark wrote:
That's strange. Deleting should be the *quickest* operation in Postgres. Do
you perchance have foreign key references referencing this table?
No.
Do you have any triggers?
No.
Tom Lane wrote:
Adriaan van Os [EMAIL PROTECTED] writes:
Surprisingly, one of the
Hello.
I've googled a bit but I think I can't match the keywords, so I thought
I'll ask here:
Let's say I've got a view with 100 columns and 1mln rows; some of them are
calculated on the fly. For some reason I want only one column from
this view:
select col1 from huge_view;
Now, does
Marcin Stępnicki wrote:
Hello.
I've googled a bit but I think I can't match the keywords, so I thought
I'll ask here:
Let's say I've got a view with 100 columns and 1mln rows; some of them are
calculated on the fly. For some reason I want only one column from
this view:
select col1 from
Le Wednesday 11 July 2007 22:35:31 Tom Lane, vous avez écrit :
Marc Cousin [EMAIL PROTECTED] writes:
Nevertheless, shouldn't the third estimate be smaller or equal to the sum
of the two others ?
The planner's estimation for subplan conditions is pretty primitive
compared to joinable
Jignesh K. Shah wrote:
Can you list others that seemed out of place?
well to me the ones that look most questionable are:
work_mem=100MB - so this benchmark is really low concurrency(which does
not fit with max_connections=1000) and with trivial queries ?
enable_seqscan = off - why ?
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Jignesh K. Shah wrote:
Can you list others that seemed out of place?
The one which surprised me the most was the commit_delay setting. What results
led you to set that? The common wisdom on this setting is that it doesn't
accomplish its goals and
Thanks all...\timing works.
--
View this message in context:
http://www.nabble.com/TIMING-A-QUERY-tf4062567.html#a11559115
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
---(end of broadcast)---
TIP 5: don't
On Thu, Jul 12, 2007 at 09:50:42AM +0100, Heikki Linnakangas wrote:
Marcin Stępnicki wrote:
Let's say I've got a view with 100 columns and 1mln rows; some of them are
calculated on the fly. For some reason I want only one column from
this view:
select col1 from huge_view;
Now, does
Michael Fuhr wrote:
On Thu, Jul 12, 2007 at 09:50:42AM +0100, Heikki Linnakangas wrote:
Marcin Stępnicki wrote:
Let's say I've got a view with 100 columns and 1mln rows; some of them are
calculated on the fly. For some reason I want only one column from
this view:
select col1 from huge_view;
Craig James [EMAIL PROTECTED] writes:
Now here's the weird thing. I'm running a pg_restore of a database
(on the order of 4GB compressed, maybe 34M rows of ordinary data, and
15M rows in one BLOB table that's typically 2K per blob). When I do
this, ALL of the postgress backends start working
Heikki Linnakangas [EMAIL PROTECTED] writes:
Marcin StÄpnicki wrote:
Now, does PostgreSQL skip all the calculations from other columns and
executes this query faster then select * from huge_view?
In simple cases, yes.
A rule of thumb is that it's been optimized if you don't see a Subquery
On Thu, 12 Jul 2007, Gregory Stark wrote:
In any case I wouldn't think the use case for a feature like this would
actually apply in the case of a benchmark.
I've also seen a tiny setting for commit_delay (like the 10 they used) as
helping improve throughput under a heavy commit load with
Adriaan van Os [EMAIL PROTECTED] writes:
Tom Lane wrote:
When you don't quantify that statement at all, it's hard to make an
intelligent comment on it, but TRUNCATE per se shouldn't be slow.
Below are some timings, in milliseconds.
I can only conclude that you're using a seriously bad
14 matches
Mail list logo
