+++
We'd love this feature as it would really help us write better test cases !
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gregory Stark
+++
We'd love this feature as it would really help us write better test cases !
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gregory Stark
> "Shahbaz" == Shahbaz Chaudhary <[EMAIL PROTECTED]> writes:
Shahbaz> There are bound to be people in the academia (grad
Shahbaz> students, professors of CS, etc.) on this mailing list,
Shahbaz> yet I see few RDBMS courses using postgresql as an
Shahbaz> example. If people sti
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Anagh Lal <[EMAIL PROTECTED]> writes:
>> I am trying to test a new join algorithm by implementing it on
>> Postgresql. It would be great if you could give me some start
>> off pointers so as to where all in the source code I
I have a small nit
Why is it that bit.h is in src/include/utils and bit.c is in
src/backend/lib ?
I can never for the life of me remember which is in which :-)
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> Why is it that bit.h is in src/include/utils and bit.c is in
>> src/backend/lib ?
Tom> Possibly a more interestin
> "Shridhar" == Shridhar Daithankar <[EMAIL PROTECTED]> writes:
Shridhar> On Saturday 04 January 2003 03:20 am, you wrote:
>> >I am sure, many of you would like to delete this message
>> before reading, > hold on. :-)
>>
>> I'm afraid most posters did not read the message.
Hi folks
I'm trying to build the documentation for pgsql (so that I can change
it for the stuff we are building) and I'm having trouble finding the
necessary docbook stuff.
I looked at:
http://developer.postgresql.org/docs/postgres/doc-build.html
checking for onsgmls... onsgmls
chec
Our students are (unfortunately) on solaris x86 (unfortunate because I
have to do another round of testing before I deploy pgsql code for
them to hack).
Sadly, set_ps_display does not seem to have any effect in solaris
x86. At least ps only reports multiple postmaster processes and
arguments.
I
Quick question for the group
I'm assuming that the PG_TEMP_FILES_DIR for BufFile temps is
automatically under the PGDATA directory. Is that correct ?
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 1: subscrib
>>>>> "Bruce" == Bruce Momjian <[EMAIL PROTECTED]> writes:
Bruce> Tom Lane wrote:
>> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> > Sadly, set_ps_display does not seem to have any effect in solaris
>> >
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Postgres has a bad habit of becoming very confused if the
Tom> page header of a page on disk has become corrupted. In
Tom> particular, bogus values in the pd_lower field tend to make
I haven't read this piece of pgsql code very
Hi Gang
I can sense that I'm _really_ close to getting docbook working, but
not quite there yet. I'm hoping somebody can tell me where I'm
screwing up !
I'm on a Red Hat Linux 7.3 system. Although I do have openjade
installed I was finding it difficult to figure out where to point
stylesheets to
Phew .. after some more struggling with docbook I think I finally
managed to get it working. Posting here to help other folks googling
through usenet archives.
My problem was that I had DOCBOOKSTYLE set to /usr/local/share/sgml -
the directory which contained the "catalog" file. However, inspite
Why don't you use elog(LOG, instead of printf ?
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
> "Srikanth" == Srikanth M writes:
Srikanth> Dear Sir I am new to postgres and dont know the excat
Srikanth> procedure of testing my code, okay i will use elog, but
Srikanth> please tell me the procedure of testing that.
Srikanth
As you're a big fan of stealing code, why don't
> "Nailah" == Nailah Ogeer <[EMAIL PROTECTED]> writes:
Nailah> Well here's the thing. Before i was trying to use
Nailah> ShmemInitStruct in buf_init.c. The problem with this is
Nailah> that you can't shrink or grow shared memory. That is why i
Nailah> switched over and just use
Let me add my two cents ..
I think something like PostgreSQL needs two test suites - an
acceptance test (to ensure that checkins don't break functionality)
and a regression test suite.
What we call the regression test suite is really an acceptance
test. Tom Lane is absolutely right in asserting
> "Bruce" == Bruce Momjian <[EMAIL PROTECTED]> writes:
Bruce> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes: > The question
>> was whether 2PC is useful. The question wasn't if an >
>> unreliable 2PC was useful.
>>
>> My question is whether there is such
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> I'm not sure if I understand Tom's beef - I think he is
>> concerned about what happens if a subordinate does no
>From Bill Todd's post:
> This is the simple 'two-phase commit, presumed-abort' mechanism. It has no
> problems guaranteeing distributed consistency, but does suffer from the
> problem that if the coordinator *never* recovers some of the other nodes may
> be left 'in doubt' about the
Consider the explain for the following queries ..
sample=# explain select a, count(*) from foo group by a order by a;
QUERY PLAN
-
Aggregate (cost=69.83..77.33 rows=100 width=4)
-> Group
> "Bruno" == Bruno Wolff, writes:
Bruno> You might try this in 7.4. I am pretty sure a change was
Bruno> made a couple of weeks ago to let group by work with either
Bruno> sort order. Also hash aggragates have been available for
Bruno> quite a while in 7.4. This is a better pl
Friends
src/tools/find_typedef has in its prolog:
# This script attempts to find all typedef's in the postgres binaries
# by using 'nm' to report all typedef debugging symbols.
#
# For this program to work, you must have compiled all binaries with
# debugging symbols.
#
#
ANNOUNCEMENT: Availability of TelegraphCQ v0.2 (BETA release)
-
The Telegraph Team at UC Berkeley is pleased to announce the immediate
availability of TelegraphCQ v0.2 (a BETA release). TelegraphCQ is a
system for processing long-running
Once more unto the breach -
Could you please abstain from sending HTML email to the list ?
Many thanks !
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> "Jenny -" <[EMAIL PROTECTED]> writes:
>> Iam trying to acquire rowlevel locks in postgresql. I try doing
>> this: 'select * from students where name='Larry' for update;
>> But by looking at the holding array of proclock , I'v
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> That doesn't work, unless you insist that the first backend
Tom> can't exit its transaction until all the other ones are done.
Tom> Which introduces its own possibilities for deadlock --- but
Tom> even worse, how does the fir
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Rod Taylor <[EMAIL PROTECTED]> writes:
>> It may be best to have a locking manager run as a separate
>> process. That way it could store locks in ram or spill over to
>> disk.
Tom> Hmm, that might be workable. We could
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> Why not have the traditional approach of a lock table in shared
>> memory, growing and shrinking as appropriate,
Tom&
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Sailesh Krishnamurthy <[EMAIL PROTECTED]> writes:
>> We implemented a Shared Memory MemoryContext using OSSP libmm
>> (used in Apache) for TelegraphCQ.
Tom> How po
> "Bruce" == Bruce Momjian <[EMAIL PROTECTED]> writes:
>> -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh
Bruce> ^^^ Watch out, that code from
Bruce> Berkeley usually is a mess. :-)
LOL !
That's why we release the code - in the hope of getting r
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> Personally I'd feel more comfortable with a shared-lock
Tom> approach, if we could work out the scalability issues. Dirty
Tom> reads seem ... well ... dirty.
Tom
I was going to do some experiments to measure the costs of our
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> AFAIK, no commercial database does predicate locking either,
True ..
Tom> so we all fall short of true serializability. The usual
Tom> solution if you need the sort of behavior you're talking
Tom> about is to take a non-s
If you read the autovacuum_naptime into an Interval object once, why can't
you just use timestamptz_pl_interval ? You won't be using the interval
input/output repeatedly surely.
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
---
gt;> for v.7.3.Is there any alternatives for the latest version of PostgreSQL
?
>
> The TelegraphCQ team has stopped public development. So it's
> pretty much waiting for someone to take on their code.
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamate
As others pointed out, DirectFunctionCall2 is your friend. There is a
mailing list for TelegraphCQ. It's a Yahoo group - visit
http://groups.yahoo.com/group/telegraphcq
About accessing data from a table in another database ... we need to
know more about what exactly you're doing. Please post on
> "Kevin" == Kevin Brown <[EMAIL PROTECTED]> writes:
>> The bigger problem though with this is that it makes the
>> problem of list overflow much worse. The hard part about
>> shared memory management is not so much that the available
>> space is small, as that the available s
Re changing APIs or not.
I agree with Tom that an incremental change is easier. More
importantly, it is also easier to test your implementation.
Even if everybody agrees that the API should be changed, IMO a better
way would be to first use your implementation with the old API and go
through som
Hackers
Along with some other folks I am co-authoring a chapter on PostgreSQL
in the next edition of "Database System Concepts" by Silberschatz,
Korth and Sudarshan (http://db-book.com)
This is in the form of a "case study" and will follow the pattern in
Chapters 25,26 and 27 (Part 8 in the Tabl
>>>>> "Marc" == Marc G Fournier <[EMAIL PROTECTED]> writes:
Marc> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
>> Which brings me to another question .. has anybody considered
>> using subversion instead of CVS ?
Marc> Wh
Dear Hackers
I apologize in advance if this posting is construed as spam.
As many of you are aware, the database research group at UC Berkeley
is building TelegraphCQ, a system for processing continuous queries
over data streams. TelegraphCQ was built with the PostgreSQL source
base.
We are lo
Yes, fetching a RID list from an index scan, sorting 'em and then
fetching from the table would be a very appreciable speedup for many
queries. I would imagine that all the commercial engines do this (db2
calls it a sorted RID-list-fetch) .. and this has in fact been
discussed on -hackers before.
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> For starters, read the previous discussions of this in the
Tom> archives.
Tom> Two questions you should have answers to before starting to
Tom> implement, rather than after, are how to deal with locking
Tom> consideratio
Hackers
Are there any default query rewrite rules that kick in, in the absence
of any user-defined RULE or VIEW ?
Also, is there any place that lists any "interesting" query rewrite
that PG does on queries for perf. improvement ?
For instance, in the presence of a view or a subquery, does PG d
> "Alvaro" == Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> For instance, in the presence of a view or a subquery, does PG
>> do a subquery to join transformation ?
Alvaro> Yes, there are transformations of this sort, but they are
Alvaro> not called query rewrite in the code's
> "Alvaro" == Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> I understand that there is a cost-based optimizer anyway that
>> does the planning and selects the right plan .. but does this
>> come _after_ all these transformations ? Or does it happen
>> along with the transformat
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
>> Are these alternatives (pulling up vs not pulling up
>> subqueries) considered in different plans ?
Tom> That particular choice is not --- we do it if we can, else
Tom> not. Comparisons between different alternatives are alwa
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> This particular issue is handled as part of our Path
Tom> enumeration mechanism, but the more hard-wired sorts of
Tom> transformations that you are asking about live mostly in
Thanks again. To confirm the actual cost comparison
> "pgsql" == pgsql <[EMAIL PROTECTED]> writes:
pgsql> The have a database of information that is coming in at a
pgsql> high speed regular basis. One bit of information is a
pgsql> value. To get this value they must perform SELECT
pgsql> sum(field) FROM table. Well, this simply
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> This means that if you have only one or a few items per
Tom> bucket, the information density is awful, and you lose big on
Tom> I/O requirements compared to a btree index. On the other
Tom> hand, if you have enough items per
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> "Hicham G. Elmongui" <[EMAIL PROTECTED]> writes:
>> is there a way to pull the projection operator to the top of
>> the query plan? I wish there's a variable that can be set to do
>> so.
Tom> Could you be more specific a
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> I tend to agree with the opinion that Oracle's architecture
Tom> is based on twenty-year-old assumptions. Back then it was
Tom> reasonable to assume that database-specific algorithms could
Tom> outperform a general-purpose o
> "Josh" == Josh Berkus <[EMAIL PROTECTED]> writes:
This is an unfair characterization of XML databases, and I can say
this without accusations of bias for I vastly prefer working with the
relational model.
Josh> Actually, amusingly enough, there is a body of theory
Josh> backing XML
> "Christopher" == Christopher Browne <[EMAIL PROTECTED]> writes:
Christopher> Ah, but do "papers" honestly indicate the emergence
Christopher> of some underlying theoretical model for which
Christopher> fidelity could be evaluated?
Certainly. The model is that of semi-structured
> "Josh" == Josh Berkus <[EMAIL PROTECTED]> writes:
>> "Relational" is all about theory and proving things
>> mathematically correct. "MV" is all about engineering and
>> getting the result. And if that means pinching all the best
>> ideas we can find from relational, then we'r
DB2 supports cooked and raw file systems - SMS (System Manged Space)
and DMS (Database Managed Space) tablespaces.
The DB2 experience is that DMS tends to outperform SMS but requires
considerable tuning and administrative overhead to see these wins.
--
Pip-pip
Sailesh
http://www.cs.berkeley.e
> "Jordan" == Jordan Henderson <[EMAIL PROTECTED]> writes:
Jordan> significantly better results. I would not say it requires
Jordan> considerable tuning, but an understanding of data, storage
Jordan> and access patterns. Additionally, these features did not
Jordan> cause our
PostgreSQL most definitely works great on Solaris x86 !
At UC Berkeley, we have our undergraduate students hack on the
internals of PostgreSQL in the upper-division "Introduction to
Database Systems" class ..
http://www-inst.eecs.berkeley.edu/~cs186/
The "official" platform is Solaris x86 - tha
> "Mike" == Mike Mascari <[EMAIL PROTECTED]> writes:
Mike> Robert Treat wrote:
>> http://www-inst.eecs.berkeley.edu/~cs186/hwk0/index.html
>>
>> Are these screenshots of PgAccess on Mac OSX?
Yup .. that's from Joe Hellerstein, who was the instructor in the
Spring when I was a
> "Chris" == Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> PostgreSQL most definitely works great on Solaris x86 ! At UC
>> Berkeley, we have our undergraduate students hack on the
>> internals of PostgreSQL in the upper-division "Introduction to
>> Database Systems"
> "Greg" == Greg Stark <[EMAIL PROTECTED]> writes:
Greg> I think you're talking about situations like "where x = ? or
Greg> y = ?" or "where x = ? and y = ?"
Greg> When both `x' and `y' are indexed. It's possible to do the
Greg> index lookup, gather a list of tid pointers in
> "Mike" == Mike Mascari <[EMAIL PROTECTED]> writes:
Mike> Robert Treat wrote:
>> While some form of bitmapped indexing would be cool, other ideas might
>> be to implement different buffer manager strategies. I was impressed by
>> how quickly Jan was able to implement ARC over
> "Robert" == Robert Treat <[EMAIL PROTECTED]> writes:
Robert> allowing indexes for searching nulls, or adding
Robert> concurrency to GIST, or allowing non btree indexes to
Oh this has come up before on -hackers and I've been meaning to chime
in.
Marcel Kornacker did implement concu
> "Neil" == Neil Conway <[EMAIL PROTECTED]> writes:
Neil> It occurred to me that these kinds of poor planning
Neil> decisions could easily be detected by PostgreSQL itself:
Neil> after we've finished executing a plan, we can trivially
Neil> compare the # of results produced by
> "Hannu" == Hannu Krosing <[EMAIL PROTECTED]> writes:
Hannu> Neil Conway kirjutas P, 30.11.2003 kell 02:18:
>> Jonathan Gardner <[EMAIL PROTECTED]> writes: > 3) We
>> would implement some sort of differential view update scheme >
>> based on the paper "Efficiently Updating Mat
Hackers
Here is the definition of relation_byte_size() in optimizer/path/costsize.c:
--
/*
* relation_byte_size
*Estimate the storage space in bytes for a given number of tuples
*of a given width (size in byte
We remain sceptical about writing an RDBMS in Java. The earlier
version of TelegraphCQ was in Java and turned out to be a bit of a
pain.
Some more information:
Mehul A. Shah, Samuel Madden, Michael J. Franklin, Joseph
M. Hellerstein: Java Support for Data-Intensive Systems: Experiences
Building
We have a rude hack of temping hashed aggs to disk to deal with the
case where there is not enough memory. I don't think that's an ideal
solution, but it certainly has the code to dump to file. I can post
the patch later in the day ..
(This is some code for our undergrad db class assignment. I wa
> "Marty" == Marty Scholes <[EMAIL PROTECTED]> writes:
Marty> Why have I not seen this in any database?
Marty> There must be a reason.
For ARIES-style systems, logging parsed statements (commonly called
"logical" logging) is not preferred compared to logging data items
("physical" or
(Just a note: my comments are not pg-specific .. indeed I don't know
much about pg recovery).
> "Marty" == Marty Scholes <[EMAIL PROTECTED]> writes:
Marty> If the DB state cannot be put back to a consistent state
Marty> prior to a SQL statement in the log, then NO amount of
Marty
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> I'm not sure that this would let us catch up to what Arjen
Tom> reports as MySQL's expression evaluation speed, but it should
Tom> at least speed things up a bit with only fairly localized
Tom> changes.
I like the idea of me
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> The idea I was toying with is to generate, not "x = y" with
Tom> repeated copies of x, but "placeholder = y" where placeholder
Tom> is a dummy expression tree node. Then at runtime, the CASE
Tom> code would evaluate the test
> "CB" == Christopher Browne <[EMAIL PROTECTED]> writes:
CB> futile discussions ask for it. Notably, on an SMP system, it
CB> would be a neat idea for complex queries involving joins to
CB> split themselves so that different parts run in separate
CB> threads.
You don't really
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> instead of increasing it. And I don't want to create a
Tom> full-fledged alloc/free package for shared memory --- the
Tom> bang-for-buck ratio for that is way too low. So I'm inclined
I think I've said it before, but we actual
> "Marc" == Marc G Fournier <[EMAIL PROTECTED]> writes:
Marc> On Thu, 7 Oct 2004, Bruce Momjian wrote:
>> Added to TODO:
>>
>> * Consider parallel processing a single query
>>
>> This would involve using multiple threads or processes to do
>> optimization, sortin
IMHO the best references to parallelizing query plans are in the
Volcano papers. The Exchange operator is a really clean abstraction -
the idea is to place the Exchange operator in query plans and that way
you don't have to paralellize any other operator. Exchange takes care
of managing the IPC qu
> "Yann" == Yann Michel <[EMAIL PROTECTED]> writes:
Yann> O.K. I downloaded it :-) We will see if and how I can
Yann> help
FYI .. in case you aren't aware already:
http://portal.acm.org/citation.cfm?id=98720
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> One huge advantage is that the actual heap visiting becomes
Tom> efficient, eg you never visit the same page more than once.
Tom> (What you lose is the ability to retrieve data in index
Tom> order, so this isn't a replacement
> "Gavin" == Gavin Sherry <[EMAIL PROTECTED]> writes:
Gavin> I'm uncertain about the potential benefit of
Gavin> this. Isn't/shouldn't the effects of caching be assisting
Gavin> us here?
It all depends on how large your table is, and how busy the system is
(other pressures on the
> "Jonah" == Jonah H Harris <[EMAIL PROTECTED]> writes:
Jonah> Replying to the list as a whole:
Jonah> If this is such a bad idea, why do other database systems
Jonah> use it? As a businessperson myself, it doesn't seem
Jonah> logical to me that commercial database companies
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> People who hang around Postgres too long tend to think that
Tom> MVCC is the obviously correct way to do things, but much of
Tom> the rest of the world thinks differently ;-)
It works the other way too ... people who come from t
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> The only real solution, of course, is to acquire cross-column
Tom> statistics, but I don't see that happening in the near
Tom> future.
Another approach is a hybrid hashing scheme where we use a hash table
until we run out of mem
Hicham
For your experiments (VLDB ? :-) your best bet of specifically bolting
on a plan (if you can't convince the optimizer to do the right thing)
is to hack it in the query planner.
I've done similar hacks in the past, but only in the TelegraphCQ code
and not in PostgreSQL.
--
Pip-pip
Sail
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> and changing the buf_table hash table. The only common
Tom> operation that needs exclusive lock is reading in a page that
Tom> was not in shared buffers already, which will require at
Tom> least a kernel call and usually a w
Sounds a bit like multi-dimensional clustering ...
http://www.research.ibm.com/mdc/
After the ARC experience though ...
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
86 matches
Mail list logo
