Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Odd. Apparently the planner is picking a better plan in the function
>> context than in the subselect context --- which is strange since it
>> ought to have less information.
> [ verbose plan snipped ]
Well, that sure seems to
On Tue, 2003-07-29 at 15:09, scott.marlowe wrote:
> On 29 Jul 2003, Ron Johnson wrote:
>
> > On Tue, 2003-07-29 at 14:00, scott.marlowe wrote:
> > > On 29 Jul 2003, Ron Johnson wrote:
> > >
> > > > On Tue, 2003-07-29 at 11:18, scott.marlowe wrote:
> > > > > On 29 Jul 2003, Ron Johnson wrote:
> >
On 29 Jul 2003, Ron Johnson wrote:
> On Tue, 2003-07-29 at 14:00, scott.marlowe wrote:
> > On 29 Jul 2003, Ron Johnson wrote:
> >
> > > On Tue, 2003-07-29 at 11:18, scott.marlowe wrote:
> > > > On 29 Jul 2003, Ron Johnson wrote:
> > > >
> > > > > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
>
On Tue, 2003-07-29 at 14:00, scott.marlowe wrote:
> On 29 Jul 2003, Ron Johnson wrote:
>
> > On Tue, 2003-07-29 at 11:18, scott.marlowe wrote:
> > > On 29 Jul 2003, Ron Johnson wrote:
> > >
> > > > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
> > > > > > "GS" == Greg Stark <[EMAIL PROTECTE
On 29 Jul 2003, Ron Johnson wrote:
> On Tue, 2003-07-29 at 11:18, scott.marlowe wrote:
> > On 29 Jul 2003, Ron Johnson wrote:
> >
> > > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
> > > > > "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
> > > >
> > > > GS> "scott.marlowe" <[EMAIL PROTECT
On Tue, 2003-07-29 at 11:18, scott.marlowe wrote:
> On 29 Jul 2003, Ron Johnson wrote:
>
> > On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
> > > > "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
> > >
> > > GS> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> > >
> > > GS> But you have to actu
Tom Lane wrote:
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
explain analyze SELECT company_id , (SELECT edition FROM ONLY
public.branding_master b WHERE old_company_id = a.company_id OR company_id =
a.company_id ORDER BY b.company_id DESC LIMIT 1) from public.branding_master
On 29 Jul 2003, Ron Johnson wrote:
> On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
> > > "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
> >
> > GS> "scott.marlowe" <[EMAIL PROTECTED]> writes:
> >
> > GS> But you have to actually test your setup in practice to see if it
> > GS> hurts. A big
On Tue, 2003-07-29 at 08:14, Vivek Khera wrote:
> > "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
>
> GS> "scott.marlowe" <[EMAIL PROTECTED]> writes:
>
> GS> But you have to actually test your setup in practice to see if it
> GS> hurts. A big data warehousing system will be faster under RAID
On Tue, 2003-07-29 at 10:14, Vivek Khera wrote:
> > "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
>
> GS> "scott.marlowe" <[EMAIL PROTECTED]> writes:
>
> GS> But you have to actually test your setup in practice to see if it
> GS> hurts. A big data warehousing system will be faster under RAID
> "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
GS> "scott.marlowe" <[EMAIL PROTECTED]> writes:
GS> But you have to actually test your setup in practice to see if it
GS> hurts. A big data warehousing system will be faster under RAID5
GS> than under RAID1+0 because of the extra disks in the
G
> "TL" == Tom Lane <[EMAIL PROTECTED]> writes:
TL> Franco Bruno Borghesi <[EMAIL PROTECTED]> writes:
>> wouldn't also increasing shared_buffers to 64 or 128 MB be a good
>> performance improvement? This way, pages belonging to heavily used
>> indexes would be already cached by the database its
Rajesh Kumar Mallah <[EMAIL PROTECTED]> writes:
> explain analyze SELECT company_id , (SELECT edition FROM ONLY
> public.branding_master b WHERE old_company_id = a.company_id OR company_id =
> a.company_id ORDER BY b.company_id DESC LIMIT 1) from public.branding_master
> a limit 50;
> Total ru
On 29 Jul 2003 at 8:03, Christopher Browne wrote:
> "Shridhar Daithankar" <[EMAIL PROTECTED]> wrote:
> >It is called as pgavd..
>
> No, it is called pg_autovacuum
>
> "pgavd" was a previous attempt at this that was being distributed on
> gborg. Its parser ussage (I don't recall if it was just l
"Shridhar Daithankar" <[EMAIL PROTECTED]> wrote:
>It is called as pgavd..
No, it is called pg_autovacuum
"pgavd" was a previous attempt at this that was being distributed on
gborg. Its parser ussage (I don't recall if it was just lex or whether it
also included yacc) made it troublesome to get t
Shridhar wrote:
>There is an auto-vacuum daemon in contrib and if I understand it correctly,
>it is not getting much of a field testing. How about you guys installing it
>and trying it.
I'm one of those that has been running it; there are numerous test systems
around where it has been running off
On 29 Jul 2003 at 8:14, Peter Childs wrote:
> On Tue, 29 Jul 2003, Shridhar Daithankar wrote:
>
> > On 28 Jul 2003 at 12:27, Josh Berkus wrote:
> > > Unless you're running PostgreSQL 7.1 or earlier, you should be VACUUMing every
> > > 10-15 minutes, not every 2-3 hours. Regular VACUUM does not
On Tue, 29 Jul 2003, Shridhar Daithankar wrote:
> On 28 Jul 2003 at 12:27, Josh Berkus wrote:
> > Unless you're running PostgreSQL 7.1 or earlier, you should be VACUUMing every
> > 10-15 minutes, not every 2-3 hours. Regular VACUUM does not lock your
> > database. You will also want to increa
18 matches
Mail list logo
