RE: [HACKERS] A post-7.1 wish-list.
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. /programmer/rules1139.htm#AEN1227 - Andrew
RE: [HACKERS] GEQO status?
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 have more optimal solutions than the default seed will ever find. Surely a random seed would make the solution better on average over a large number of queries. On the other hand, if the system as a whole is working well, it should not matter what the seed is. - Andrew
Re: [HACKERS] (one more time) Patches with vacuum fixes available.
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 should be adding new features now. Also, I don't know about you, but I have enough bug fix, testing, and documentation work to keep me busy till January even without any new features... It'd be really naughty to add it to the beta at this stage. Would it be possible to add it to the 7.1 package with some kind of compile-time option? So that those of us who do want to use it, can. - Andrew
Re: [HACKERS] OK, does anyone have any better ideas?
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
RE: [HACKERS] SQL 'in' vs join.
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
RE: [HACKERS] 8192 BLCKSZ ?]
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 - therefore in my opinion it should remain at 8KB to maintain best average performance with all existing platforms. I say its best let the OS and mass storage subsystem worry about read-ahead caching and whether they actually read 8KB off the disk, or 32KB or 64KB when we ask for 8. - Andrew
Re: [HACKERS] Please advise features in 7.1 (SUMMARY)
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 basic service that needs to be implemented soon, even if its just returning multiple rows of one column... - Andrew
