On Tue, 28 Nov 2000, John Huttley wrote:
3. Stored Procedures returning a record set.
Dream on!
This is something I would be really interested to see working. What are the
issues? my understanding is that it is technically feasible but too
complicated to add to PL/PGsql? it seems to me a
The cost difference between 32K vs 8K disk reads/writes are so small
these days when compared with overall cost of the disk operation itself,
that you can even measure it, well below 1%. Remember seek times
advertised on disks are an average.
It has been said how small the difference is -
Now, given the two components, each with very low costs, it chooses to
do a sequential scan on the table. I don't get it.
Read the FAQ?
http://www.postgresql.org/docs/faq-english.html#4.23
"4.23) Why are my subqueries using IN so slow?")
- Andrew
Could you perhaps post the code you have for splitting a text field up into
keys, then I could work on turning into a new type of index with a new
operator, as Tom suggested?
(Or is this already what the text search code in contrib already does??)
- Andrew
On Mon, 11 Dec 2000, Tom Lane wrote:
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
If there are no objections then I'm ready to add changes to 7.1.
Else, I'll produce patches for 7.1 just after release and incorporate
changes into 7.2.
I'd vote for the second choice. I do not think we
I would set Seed per default. Even worse than a bad query path
is an unpredictable query path. I see no argument, that a random Seed
would buy us anything.
This kindof bugs me -- if you leave it stuck at a preset value, it makes it
possible to never delve into parts of solution space that
I'd try my hand at it, given enough time ... which I'm awfully short on.
Which is one of my reasons to have that feature : not having to do grunt
work.
It should only take a few seconds to write such rules for simple views --
see the examples in the Programmer documentation.
