Hiroshi Inoue wrote:
> I've not seen your reply yet.
You keep sending your emails to randomly invented addresses, so I don't
get them.
I think your questions have been answered in the meantime. If not,
please address them to me.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
-
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marshall, Steve" <[EMAIL PROTECTED]> writes:
> > I have developed a small patch to optimizer/util/plancat.c that
> > eliminates one of hte caveats associated with constraint exclusions,
> > namely the inability to avoid searching tables based on the result
Am Dienstag, 8. Mai 2007 01:45 schrieb Hiroshi Inoue:
> Must I mail them directly to you in the first place ?
Yes.
> Please note that the question is to your recent sudden change to
> psqlodbc.
These are the same files that psqlodbc has been shipping for years. Just now
they are in the CVS rep
Here's my roadmap for the "scan-resistant buffer cache" and
"synchronized scans" patches.
1. Fix the current vacuum behavior of throwing dirty buffers to the
freelist, forcing a lot of WAL flushes. Instead, use a backend-private
ring of shared buffers that are recycled. This is what Simon's
"
Heikki,
On 3A: In practice, the popular modern OS'es (BSD/Linux/Solaris/etc)
implement dynamic I/O caching. The experiments have shown that benefit
of re-using PG buffer cache on large sequential scans is vanishingly
small when the buffer cache size is small compared to the system memory.
Since t
ITAGAKI Takahiro wrote:
Tom Lane <[EMAIL PROTECTED]> wrote:
"Marshall, Steve" <[EMAIL PROTECTED]> writes:
I have developed a small patch to optimizer/util/plancat.c that
eliminates one of hte caveats associated with constraint exclusions,
namely the inability to avoid searching table
Luke Lonergan wrote:
On 3A: In practice, the popular modern OS'es (BSD/Linux/Solaris/etc)
implement dynamic I/O caching. The experiments have shown that benefit
of re-using PG buffer cache on large sequential scans is vanishingly
small when the buffer cache size is small compared to the system m
Heikki,
> That's interesting. Care to share the results of the
> experiments you ran? I was thinking of running tests of my
> own with varying table sizes.
Yah - it may take a while - you might get there faster.
There are some interesting effects to look at between I/O cache
performance and PG
Luke Lonergan wrote:
What do you mean with using readahead inside the heapscan?
Starting an async read request?
Nope - just reading N buffers ahead for seqscans. Subsequent calls use
previously read pages. The objective is to issue contiguous reads to
the OS in sizes greater than the PG page
On Tue, May 08, 2007 at 08:08:28AM -0400, Marshall, Steve wrote:
> However, I think it would be possible to expand immutable functions
> operating on constants to optimize constraint exclusion. Immutable
> functions will always return the same result given the same inputs, so
> this would be sa
Peter Eisentraut wrote:
> Am Dienstag, 8. Mai 2007 01:45 schrieb Hiroshi Inoue:
>> Must I mail them directly to you in the first place ?
>
> Yes.
Oh I seem to have been apart from the community too long.
Could you please tell me where I can find the rule ?
regards,
HIroshi Inoue
---
"Marshall, Steve" <[EMAIL PROTECTED]> writes:
> Currently, immutable functions are not expanded
> during planning
Incorrect, see eval_const_expressions().
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched
Hi,
I am migrating from Sybase to Postgres.
trying to get a hold on the issue of future releases feature list.
1. Where can I find the feature list for 8.3 ? When is it expected?
2. And for 8.4?
3. Who is the guy to ask about a feature like "startup migrate" in ORACLE?
Thanks
Danny
---
Abraham, Danny wrote:
Hi,
I am migrating from Sybase to Postgres.
trying to get a hold on the issue of future releases feature list.
1. Where can I find the feature list for 8.3 ? When is it expected?
2. And for 8.4?
There are various places to look for this kind of information, but
probab
On Mon, May 07, 2007 at 07:36:55AM -0500, Jim Nasby wrote:
> Instead, if all feature requests are tracked then users can vote on
> what's most important to them.
I am sympathetic to the issues you and Andrew are describing (I
understand Bruce's stream analogy, but I think Andrew is right that
f
Am Dienstag, 8. Mai 2007 15:12 schrieb Hiroshi Inoue:
> Oh I seem to have been apart from the community too long.
> Could you please tell me where I can find the rule ?
The only "rule" there is is that if you want to talk to person X, you write to
person X. That rule is as old as communications.
> Nope - just reading N buffers ahead for seqscans. Subsequent
> calls use previously read pages. The objective is to issue
> contiguous reads to the OS in sizes greater than the PG page
> size (which is much smaller than what is needed for fast
> sequential I/O).
Problem here is that eight
> >> What do you mean with using readahead inside the heapscan?
> >> Starting an async read request?
> >
> > Nope - just reading N buffers ahead for seqscans. Subsequent calls
> > use previously read pages. The objective is to issue
> contiguous reads
> > to the OS in sizes greater than the
Andrew Sullivan wrote:
On Mon, May 07, 2007 at 07:36:55AM -0500, Jim Nasby wrote:
Instead, if all feature requests are tracked then users can vote on
what's most important to them.
I am sympathetic to the issues you and Andrew are describing (I
understand Bruce's stream analogy, bu
On May 8, 2007, at 9:50 AM, Andrew Sullivan wrote:
On Mon, May 07, 2007 at 07:36:55AM -0500, Jim Nasby wrote:
Instead, if all feature requests are tracked then users can vote on
what's most important to them.
I am sympathetic to the issues you and Andrew are describing (I
understand Bruce's st
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>> Are you filling multiple buffers in the buffer cache with a
>> single read-call?
>
> yes, needs vector or ScatterGather IO.
I would expect that to get only moderate improvement. To get the full benefit
I would think you would want to e
Jim Nasby wrote:
On May 8, 2007, at 9:50 AM, Andrew Sullivan wrote:
On Mon, May 07, 2007 at 07:36:55AM -0500, Jim Nasby wrote:
Instead, if all feature requests are tracked then users can vote on
what's most important to them.
I am sympathetic to the issues you and Andrew are describing (I
und
Ale Raza <[EMAIL PROTECTED]> writes:
> Attached is the modified pg_statistic.h file for this patch. As you
> mentioned 200 - 299 is reserved for ESRI st_geometry type. Out of these
> values I am using code 200 for st_geometry.
Done.
For future reference, what people normally mean by a "patch" is
Magnus Hagander wrote:
> Alvaro Herrera wrote:
>> Jim Nasby wrote:
>>
>>> If we really want to make the logfile the approved method for
>>> monitoring performance, then why do we have the stats infrastructure
>>> at all? It could all be replaced with logging output and pgfouine.
>> First we'd h
Hi,
guess I missed hackers on my initial reply. So I am re-sending the reply
I send to Joshua based on the reply I send to him in regards to a
hackers@ posting.
Read below.
regards,
Lukas
Joshua D. Drake wrote:
That being said, it seems obvious that so far PostgreSQL has been
mainly dr
Hi,
We are using the following piece of code for updating a list
synchronously i.e. no two threads would update the list at a time. But
the postgres hangs for some reason after a few calls to UpdateList
function. The program (i.e. postgres) does not even react to Ctrl+C or
any other interrupt. We
On Wed, 2007-09-05 at 01:07 +0530, Raja Agrawal wrote:
> We are using the following piece of code for updating a list
> synchronously i.e. no two threads would update the list at a time.
Do you mean threads or processes?
> Is the following way of using semaphores not correct in the postgres
> env
This thread here became a TODO item:
http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php
During that discussion a patch was produced that nobody seemed to have
objections to. The main problem seemed to be that it wouldn't always
downgrade the lock on a ROLLBACK TO (as I understand
Ale Raza wrote:
> Ok, Thanks, Which release it will be in, PostgreSQL 8.2.5?
8.3, but you can actually use the numbers in whatever release you
please as it is unlikely that they would have been used by anyone else
(much less somebody with which you would be sharing a database).
--
Alvaro Herrer
On Tue, 2007-05-08 at 11:40 +0100, Heikki Linnakangas wrote:
> I'm going to do this incrementally, and we'll see how far we get for
> 8.3. We might push 3A and/or 3B to 8.4. First, I'm going to finish up
> Simon's patch (step 1), run some performance tests with vacuum, and
> submit a patch for t
On Tue, 2007-05-08 at 07:47 -0400, Luke Lonergan wrote:
> Heikki,
>
> On 3A: In practice, the popular modern OS'es (BSD/Linux/Solaris/etc)
> implement dynamic I/O caching. The experiments have shown that benefit
> of re-using PG buffer cache on large sequential scans is vanishingly
> small when t
Peter Eisentraut wrote:
> Am Dienstag, 8. Mai 2007 15:12 schrieb Hiroshi Inoue:
>> Oh I seem to have been apart from the community too long.
>> Could you please tell me where I can find the rule ?
>
> The only "rule" there is is that if you want to talk to person X, you write
> to
> person X. T
32 matches
Mail list logo
