Quoting nori <[EMAIL PROTECTED]>:
> Hi,
>
> If I have:
> 1.) table car with columns index and name
> 2.) table driver with columns index, name and car_index
>
> and query:
> SELECT d.*, c.* FROM driver as d LEFT OUTER JOIN car AS c ON
> d.car_index=c.index;
>
> How can I get results that have
Hi,
If I have:
1.) table car with columns index and name
2.) table driver with columns index, name and car_index
and query:
SELECT d.*, c.* FROM driver as d LEFT OUTER JOIN car AS c ON
d.car_index=c.index;
How can I get results that have distinct names for columns (ex.
d.name, d.index, c.name,
On Tue, Aug 02, 2005 at 14:34:46 -0400,
Henry Ortega <[EMAIL PROTECTED]> wrote:
> I have the ff table:
>
> id |total| effective|end_date
> john 6 01-01-200502-28-2005
> john 8 03-01-200506-30-2005
>
> How
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I believe running count(*) means fulltable scan, and there's no way
> > to do it without it. But what about some "intermediate" table, with
> > the necessary counts?
>
> There's a fairly complete discussion in the PG list archives of a
> reasonably-e
Owen Jacobson wrote:
Salve.
I understand from various web searches and so on that PostgreSQL's MVCC
mechanism makes it very hard to use indices or table metadata to optimise
count(*). Is there a better way to guess the "approximate size" of a table?
Plenty of good answers on how to estimate t
On Tue, Aug 09, 2005 at 09:29:13PM -0600, Michael Fuhr wrote:
> On Tue, Aug 09, 2005 at 10:49:14PM -0400, Tom Lane wrote:
> > Current best practice is to run the explain and parse out the "rows"
> > figure using a perl (or axe-of-choice) regexp, though we could be
> > persuaded to supply a simpler
On Tue, Aug 09, 2005 at 10:49:14PM -0400, Tom Lane wrote:
>
> Current best practice is to run the explain and parse out the "rows"
> figure using a perl (or axe-of-choice) regexp, though we could be
> persuaded to supply a simpler API if there's enough demand for it.
FWIW, this was another one of
