On Mon, Nov 7, 2011 at 10:33 PM, Bhakti Ghatkar wrote:
> Tom,
>
> Currently we are using version 9.0.1.
>
> Which version shall we update to? 9.05 or 9.1 ?
>
9.0.5 should be compatible with your installed db and contain any bug fixes
that have been released. Which isn't to say that you shouldn'
Tom,
Currently we are using version 9.0.1.
Which version shall we update to? 9.05 or 9.1 ?
~Bhakti
On Fri, Nov 4, 2011 at 7:44 PM, Tom Lane wrote:
> Bhakti Ghatkar writes:
> > Hi ,
> > While performing full vacuum we encountered the error below:
>
>
> > INFO: vacuuming "pg_catalog.pg_index"
Hi all,
Thanks for all your responses.
Sorry for late response
Earlier we used Postgres8.3.10 with Desktop computer (as server) and
configuration of the system (I2 core with 4GB RAM) and also the application
was slow i dint change any postgres config settings.
May be because of low config We t
Jay Levitt wrote:
And yep! When I do a CREATE TABLE AS from that view, and add an index on
user_id, it works just as I'd like.
Or not. Feel free to kick me back over to pgsql-novice, but I don't get why
the GROUP BY in this subquery forces it to scan the entire users table (seq
scan here, in
Kevin Grittner wrote:
"Kevin Grittner" wrote:
If I had made the scores table wider, it might have gone from the
user table to scores on the index.
Bah. I just forgot to put an index on scores.user_id. With that
index available it did what you were probably expecting -- seq scan
on question
"Kevin Grittner" wrote:
> If I had made the scores table wider, it might have gone from the
> user table to scores on the index.
Bah. I just forgot to put an index on scores.user_id. With that
index available it did what you were probably expecting -- seq scan
on questions, nested loop index
Hi Everyone,
I recently saw a crash on one of our databases, and I was wondering if this
might be an indication of something with WAL that might be unexpectedly
creating more files than it needs to?
Nov 5 16:18:27 localhost postgres[25092]: [111-1] 2011-11-05 16:18:27.524
PDT [user=slony,db=uk d
Jay Levitt wrote:
> When I run the following query:
>
> select questions.id
> from questions
> join (
> select u.id as user_id
> from users as u
> left join scores as s
> on s.user_id = u.id
> ) as subquery
> on subquery.user_id = questions.user_id;
>
> the subquery is scanni
Jay Levitt writes:
> When I run the following query:
> select questions.id
> from questions
> join (
> select u.id as user_id
> from users as u
> left join scores as s
> on s.user_id = u.id
> ) as subquery
> on subquery.user_id = questions.user_id;
> the subquery is scanning m
When I run the following query:
select questions.id
from questions
join (
select u.id as user_id
from users as u
left join scores as s
on s.user_id = u.id
) as subquery
on subquery.user_id = questions.user_id;
the subquery is scanning my entire user table, even though it's restri
On Fri, Nov 4, 2011 at 4:07 PM, Claudio Freire wrote:
>> Here again, you've set it to ten times the default value. That
>> doesn't seem like a good idea. I would start with the default and
>> tune down.
>
> Already did that. Waiting to see how it turns out.
Nope, still happening with those chan
Jay Levitt wrote:
Yes, that patch works great! Oddly enough, the workaround now does NOT work;
functions returning SETOF named composite types don't get inlined, but
functions returning the equivalent TABLE do get inlined. Let me know if you
need a failcase, but the bug doesn't actually affect me
Tom Lane wrote:
> Please don't send HTML-only email to these lists.
Oops - new mail client, sorry.
> Anyway, the answer seems to be that inline_set_returning_function needs
> some work to handle cases with declared OUT parameters. I will see
> about fixing that going forward, but in existing re
On 07/11/2011 11:36, Lucas Mocellin wrote:
> Hi everybody,
>
> I'm having some issues with PostgreSQL 9.03 running on FreeBSD 8.2 on top
> of VMware ESXi 4.1 U1.
I hope your hardware is Nehalem-based or newer...
> The problem is query are taking too long, and some times one query "blocks"
> ever
On Mon, Nov 07, 2011 at 08:36:10AM -0200, Lucas Mocellin wrote:
> Hi everybody,
>
> I'm having some issues with PostgreSQL 9.03 running on FreeBSD 8.2 on top
> of VMware ESXi 4.1 U1.
>
> The problem is query are taking too long, and some times one query "blocks"
> everybody else to use the DB as
On 7 Listopad 2011, 11:36, Lucas Mocellin wrote:
> Hi everybody,
>
> I'm having some issues with PostgreSQL 9.03 running on FreeBSD 8.2 on top
> of VMware ESXi 4.1 U1.
>
> The problem is query are taking too long, and some times one query
> "blocks"
> everybody else to use the DB as well.
>
> I'm a
Hi everybody,
I'm having some issues with PostgreSQL 9.03 running on FreeBSD 8.2 on top
of VMware ESXi 4.1 U1.
The problem is query are taking too long, and some times one query "blocks"
everybody else to use the DB as well.
I'm a network administrator, not a DBA, so many things here can be "new
17 matches
Mail list logo
