4) Currently, pg_dump does *not* back up statistics settings.
Is this a TODO?
Oops - sorry I thought you meant 'pg_dump does not back up statistics'.
Probably still should be a TODO :)
Chris
---(end of broadcast)---
TIP 2: you can get off al
4) Currently, pg_dump does *not* back up statistics settings.
Is this a TODO?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
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
Neil,
> > 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?
For the more granular stats to be useful, they have to be accurate; otherwise
you'll go back to a nestloop as soon as th
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
Jeremiah,
> Thanks to all, I had already run analyze. But the STATISTICS setting
> seems to have worked. I'm just not sure what it did..? Would anyone care
> to explain.
The STATISTICS setting improves the granularity of statistics kept by the
query planner on that column; increasing the granul
Thanks to all, I had already run analyze. But the STATISTICS setting
seems to have worked. I'm just not sure what it did..? Would anyone care
to explain.
On Mon, 2003-12-01 at 13:47, Josh Berkus wrote:
> Jeremiah,
>
> > I've attached the Analyze below. I have no idea why the db thinks there
>
Jeremiah,
> I've attached the Analyze below. I have no idea why the db thinks there
> is only 1 judge named simth. Is there some what I can inform the DB
> about this. In actuality, there aren't any judges named smith at the
> moment, but there are 22K people named smith.
No, Hannu meant that you
> Jeremiah Jahn wrote:
>
> > Have you run ANALYZE ? Why does DB think that there is only
> one judge
> > with name like SMITH% ?
> I've attached the Analyze below. I have no idea why the db
> thinks there is only 1 judge named simth. Is there some what
> I can inform the DB about this. In actua
On Monday 01 December 2003 14:29, Jeremiah Jahn wrote:
> On Wed, 2003-11-26 at 16:32, Hannu Krosing wrote:
> > Jeremiah Jahn kirjutas K, 26.11.2003 kell 22:14:
> > > I was wondering if there is something I can do that would act similar
> > > to a index over more than one table.
> > >
> > > I have a
On Wed, 2003-11-26 at 16:32, Hannu Krosing wrote:
> Jeremiah Jahn kirjutas K, 26.11.2003 kell 22:14:
> > I was wondering if there is something I can do that would act similar to
> > a index over more than one table.
> >
> > I have about 3 million people in my DB at the moment, they all have
> > r
Jeremiah Jahn kirjutas K, 26.11.2003 kell 22:14:
> I was wondering if there is something I can do that would act similar to
> a index over more than one table.
>
> I have about 3 million people in my DB at the moment, they all have
> roles, and many of them have more than one name.
>
> for exam
Sybase IQ lets you build "joined indexsets". This is amazing but pricey
and really intended more for Data Warehousing than OLTP, although they did
release a version which permitted writes on-the-fly. (This was implemented
using a multi-concurrency solution much like PostreSQL uses.)
It essential
I was wondering if there is something I can do that would act similar to
a index over more than one table.
I have about 3 million people in my DB at the moment, they all have
roles, and many of them have more than one name.
for example, a Judge will only have one name, but a Litigant could have
14 matches
Mail list logo
