On 10/12/07, Tom Lane [EMAIL PROTECTED] wrote:
Andreas Joseph Krogh [EMAIL PROTECTED] writes:
Will $SUBJECT make it possible for count(*) to use index? This is a much
wanted feature.
If you mean count(*) will become instantaneous, no it won't. It would
get faster, but probably not by
On Sat, 2007-10-13 at 11:12 +0530, Gokulakannan Somasundaram wrote:
b) But i don't understand how storing the visibility info in TOAST
table would help you. In that case you may need to update it for every
delete/ update happening in the main table. Only thing, it would help
is if someone
It seems that we are faced with a choice of two evils:
1. Accept that there's an ABI break and increment libpq.so's major
version number for 8.3. This will be a PITA for packagers, who will
have to carry a compatibility package to provide 8.2 libpq.so.
2. Renumber 8.3's encoding IDs to
Gokulakannan Somasundaram [EMAIL PROTECTED] writes:
I accept that the indexes will be bigger in size for this approach. You
might need more disk-space and you might need more memory to accomodate the
same amount of information. But i think disk costs and memory costs have
come down a lot,
Hi,
I went through this article and it was good. Please have a look at it.
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
This article was written by Michael Stonebraker, considered to be the
founder of our database. He has mentioned that the DBMS designed in 1970s
haven't
On 10/13/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
I accept that the indexes will be bigger in size for this approach. You
might need more disk-space and you might need more memory to accomodate the
same amount of information. But i think disk costs and memory costs have
come
On 10/13/07, Gokulakannan Somasundaram [EMAIL PROTECTED] wrote:
Hi,
I went through this article and it was good. Please have a look at it.
http://www.databasecolumn.com/2007/09/one-size-fits-all.html
This article was written by Michael Stonebraker, considered to be the
founder of our
We are presently investigating to migrate large
(10 TB) databases from Oracle to PostgreSQL. We find the need
for table partitioning and the support of that is not good in
PgSQL. We think the problem might be important enough to reach
out to someone who might help us. Our idea is that a
SHARMILA JOTHIRAJAH [EMAIL PROTECTED] writes:
Now for
SELECT * FROM Foo WHERE b='2'
it should know to access only Foo_2, I suppose it could be done
with a rule, but that should work even if b='2' is implicitly
given (not just if b = constant) is stated explicitly.
This much already exists
I have two doc updates I'd like to offer. I see we have two example
sections: creating rule-based dict's and creating parsers. When I was
starting I would have liked to see an example usage.
I'd like to offer: example usage and Upgrading.
This is my first draft, if anyone has suggestions I'd
Hm, I suppose this is expected. I always hated the idea that libraries could
introduce new symbols without an soname bump but obviously nobody's going to
be interested in an soname bump today...
!
/home/stark/src/local-HEAD/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql:
Andy,
note that documentation is discussed in the pgsql-docs list and patches
usually are submitted to the pgsql-patches list. Nice to see both new
sections, by the way.
A Diumenge 14 Octubre 2007, andy va escriure:
I have two doc updates I'd like to offer. I see we have two example
Magnus Hagander [EMAIL PROTECTED] writes:
Might be worthwhile to try to get beta2 out as quickly as we can after the
changes are in, to minimize the number of people who will need it?
I'd like to get the locale/encoding issues straightened out, and also
get the contrib-tsearch-examples stuff
13 matches
Mail list logo
