compliance).
Any ideas what status is on this stuff? Should I dive in and try to do it
myself?
Glen Parker
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
.
Just my $.02
Glen Parker
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
I want to come hug you --- where do you live? !!!
You're not the only one. But we don't want to smother the poor guy, at
least not before he completes his work :-)
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an
performance. This could be a completely
seperate implementation task. With clean sequential index access *and*
clean sequential heap access, it might just prove to be the single largest
performance boost PG has seen, well, ever.
My .02...
Glen Parker
---(end of broadcast
for heap tuples would be sorted differently.
Glen Parker
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
Sent: Wednesday, May 19, 2004 11:56 AM
Not unless you add yet another sort step after the fetch step, that is
the idea becomes
1. read index to get candidate TIDs
2. sort TIDs into
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
Or:
2. Sort AND COPY TID's into physical order.
3. Read heap in phy. order, match results to un-sorted TID list.
That sounds quite cheap.
No, it sounds like handwaving. What's your
so, IMO.
Glen Parker
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Simon Riggs wrote:
On Thu, 2004-07-15 at 23:18, Devrim GUNDUZ wrote:
Thanks for the vote of confidence, on or off list.
too many people spend a lot of
money for proprietary databases, just for some missing features in
PostgreSQL
Agreed - PITR isn't aimed at existing users
I'll throw in my vote, I would find this quite useful.
-Glen
Florian G. Pflug wrote:
I plan to submit a proposal for implementing support for
read-only queries during wal replay as a Google Summer of Code 2007
project.
I've been browsing the postgres source-code for the last few days,
and
Andrew Dunstan wrote:
Well, yes, it's some of it, and in theory Tom's late addition of a queue
that gets all the dependencies of a table as soon as the table data is
restored should make that work better. But of course, that's not the
only time indexes are created, and each index creation
11 matches
Mail list logo
