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
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 many
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 "Su
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 wo
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;
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;
> >
>
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 forg
"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 goa
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 ?
effectiv
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 joinab
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 huge
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 PostgreS
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 bottlen
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 fin
14 matches
Mail list logo
