Tom Lane wrote:
Great Bridge did essentially that years ago, but I think we only got
away with it because we didn't say which DBs "Commercial Database A"
and "Commercial Database B" actually were. Even off the record, we
were only allowed to tell people that the commercial DBs were Oracle
and SQL
Christopher Browne <[EMAIL PROTECTED]> writes:
> After all, the cost of a computer system to run the transactions is
> likely to be comprised of some combination of software licenses and
> hardware costs. Even if the software is free, the hardware isn't.
And labour costs.
--
greg
---
Dear,
We are using PostgreSQL for 4 Years now, one can say it is a blessing to
maintain. Our previous database was number one (;-), it was much harder
to maintain so labor is a pro for PostgreSQL ...
Kind Regards
Patrick Meylemans
IT Manager
WTCM-CRIF
Celestijnenlaan 300C
3001 Helerlee
At 11:34
Hi,
in the #postgresql-es channel someone shows me this:
pgsql-7.4.5 + postgis
--- begin context ---
CREATE TABLE calles (
gid int4 NOT NULL DEFAULT nextval('public.callesstgo_gid_seq'::text),
nombre varchar,
inicio int4,
termino int4,
comuna varchar,
ciudad varchar,
region numer
Jaime,
> Why is this query using a seq scan rather than a index scan?
Because it thinks a seq scan will be faster.
> i notice
> the diff between the estimated rows and actual rows (almost 2000).
Yes, ANALYZE, and possibly increasing the column stats, should help that.
> Can this affect the q
On Sun, 13 Feb 2005 13:41:09 -0800, Josh Berkus wrote:
> Jaime,
>
> > Why is this query using a seq scan rather than a index scan?
>
> Because it thinks a seq scan will be faster.
>
I will suggest him to probe with seq scans disabled.
But, IMHO, if the table has 143902 and it thinks will retri
Jaime Casanova <[EMAIL PROTECTED]> writes:
> But, IMHO, if the table has 143902 and it thinks will retrieve 2610
> (almost 1.81% of the total). it won't be faster with an index?
That's almost one row in fifty. We don't know how wide the table is,
but it's certainly possible that there are order-o
Jaime Casanova wrote:
But, IMHO, if the table has 143902 and it thinks will retrieve 2610
(almost 1.81% of the total). it won't be faster with an index?
Depends on how those 2610 rows are distributed amongst the 143902. The
worst case scenario is each one of them in its own page. In that case
you
