G B writes:
> How can explain-analyze return significantly much faster than other means?
If the returned data is large or takes a lot of work to convert to text,
this could happen, since EXPLAIN ANALYZE doesn't bother to format the
tuples for display. How big are those bytea columns, on average
On Thu, Oct 08, 2009 at 03:37:39PM -0500, Kevin Grittner wrote:
> Justin T Pryzby wrote:
> > On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote:
> >> Did your scheduler change between the kernel versions?
> > No, it's deadline for both.
>
> How about write barriers? I had a kernel
Justin T Pryzby wrote:
> On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote:
>> Did your scheduler change between the kernel versions?
> No, it's deadline for both.
How about write barriers? I had a kernel upgrade which turned them on
for xfs, with unfortunate performance impacts.
Hi there
We are runing Postgres 8.3.7 on a
We have a problem with Explain Analyze that we haven't seen before.
we run an Explain Analyze on a query.
Nested Loop (cost=1256.32..2097.31 rows=198 width=1120) (actual
time=12.958..20.846 rows=494 loops=1)
-> HashAggregate (cost=1256.32..1256
On Thu, Oct 08, 2009 at 10:49:37AM -0700, Joshua D. Drake wrote:
> On Thu, 2009-10-08 at 10:44 -0700, Justin T Pryzby wrote:
> > Hi Everyone
> Did your scheduler change between the kernel versions?
No, it's deadline for both.
Justin
--
Sent via pgsql-performance mailing list (pgsql-performance@
On Thu, Oct 8, 2009 at 11:55 AM, Tom Lane wrote:
> I wouldn't be too surprised if the LOCK is coming from some Slony
> operation or other. You might want to ask the slony hackers about it.
I've had issues like this. Shutting down the slon daemons before
running such commands would usually allow
Tory M Blue writes:
> *2009-10-07 22:18:02 PDT admissionclsdb postgres 10.13.200.70(46706) ERROR:
> deadlock detected*
> *2009-10-07 22:18:02 PDT admissionclsdb postgres 10.13.200.70(46706)
> DETAIL: Process 20939 waits for ShareLock on virtual transaction
> 16/43817381; blocked by process 1874.
On Thu, 2009-10-08 at 10:44 -0700, Justin T Pryzby wrote:
> Hi Everyone
Did your scheduler change between the kernel versions?
> Not sure if sar can provide other data included by vmstat: IO merged
> in/out, {,soft}irq ticks?
>
> Thanks,
> Justin
>
--
PostgreSQL.org Major Contributor
Command
Hi Everyone
On Fri, Oct 02, 2009 at 12:58:12PM -0700, Justin Pryzby wrote:
> When we upgraded from linux-2.6.24 to linux-2.6.27, our pg_dump
> duration increased by 20% from 5 hours to 6. My first attempt at
On Sat, Oct 03, 2009 at 11:31:11PM -0600, Scott Marlowe wrote:
> between these two to te
Hey all, it's been a bit however I'm running into some issues with my
concurrent index
Always get this error during a concurrent index.
*2009-10-07 22:18:02 PDT admissionclsdb postgres 10.13.200.70(46706) ERROR:
deadlock detected*
*2009-10-07 22:18:02 PDT admissionclsdb postgres 10.13.200.70(
We have been using partitioning for some time with great success. Up
until now our usage has not included ordering and now that we are trying
to use an ORDER BY against an indexed column a rather significant
shortcoming seems to be kicking in.
Parent table (have cut all but 4 columns to make
Matthew Wakeling writes:
> Postgres does not split rows across multiple pages, so this should never
> be a concern. When a row is too big for a page, Postgres will select the
> larger of the columns from the row and compress them. If that fails to
> bring the row size down, then Postgres will s
On Thu, 8 Oct 2009, Michael Gould wrote:
In other SQL engines that I've used, it is recommended that the columns that
are used in
various indexes be placed at the beginning of a row since at some point
(depending on the
engine and/or pagesize) wide rows could end up on other pages. From a
per
In other SQL engines that I've used, it is recommended that the columns that
are used in various indexes be placed at the beginning of a row since at
some point (depending on the engine and/or pagesize) wide rows could end up
on other pages. From a performance standpoint on large tables this makes
On Mon, 5 Oct 2009, Jean-Michel Pouré wrote:
Go for Debian:
* It is a free community, very active.
* It is guaranteed to be upgradable.
* Very easy to administrate via apt-get.
http://www.debian.org/News/2009/20091007
If you like Debian, but want to use FreeBSD, now you can have both.
Choose
HiI have a database and ~150 clients non-stop writing to this database quite
big pieces of text.
I have a performacne problem so I tried to increase log level, so I could
see which queries take most time.
My postgresql.conf (Log section) is:
log_destination = 'stderr'
logging_collector = on
log_ro
16 matches
Mail list logo