> 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/ru
I suppose it won't help here to suggest using memory mapped I/O, because
someone will complain their platform doesn't support it. I wonder though if
there could be an optional patch to use mmap for all disk I/O, not just
shared memory!
- Andrew
> 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 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
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
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
> 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
> 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
On Thu, 30 Nov 2000, Thomas Lockhart wrote:
> > Is "if" clause support in PG?
> > for example:
> > "drop table aa if exist"
> > "insert into aa values(1) if not exists select * from aa where i=1"
>
> No. afaict it is not in any SQL standard, so is unlikely to get much
> attention from developer
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
10 matches
Mail list logo
