On Sat, Jul 29, 2006 at 09:14:16PM -0400, Greg Sabino Mullane wrote:
> Today on IRC David Fetter and some others were discussing version
> numbers and we realized that although libpq now provides the version
> of Postgres as a number, this is still a wheel that is being
> reinvented by apps many ti
Heikki Linnakangas wrote:
> Ron Mayer wrote:
>> In my case my biggest/slowest tables are clustered by zip-code (which
>> does a reasonable job at keeping counties/cities/etc on the
>> same pages too)
>
> No deletes? If the tables grow over time, you probably would need to run
> CLUSTER every n
On Aug 10, 2006, at 7:57 AM, Tom Lane wrote:
Anyway, after further thought I've concluded that we really should
supply something that returns the Insert pointer, as this would be
useful for debugging and system-monitoring purposes. It's clear
however
that we also need something that returns t
Ron Mayer wrote:
In my case my biggest/slowest tables are clustered by zip-code (which
does a reasonable job at keeping counties/cities/etc on the
same pages too). Data comes in constantly (many records per minute, as
we ramp up), pretty uniformly across the country; but most queries
are geograp
Yoshiyuki Asaba wrote:
> Hi,
>
> I see a performance issue on win32. This problem is causes by the
> following URL.
>
> http://support.microsoft.com/kb/823764/EN-US/
>
> On win32, default SO_SNDBUF value is 8192 bytes. And libpq's buffer is
> 8192 too.
>
> pqcomm.c:117
> #define PQ_BUFFER_SI
Tom Lane wrote:
> Gene <[EMAIL PROTECTED]> writes:
>> I have a table that inserts lots of rows (million+ per day) int8 as primary
>> key, and I cluster by a timestamp which is approximately the timestamp of
>> the insert...
>
> ISTM you should hardly need to worry about clustering that --- the dat
Patch applied. Thanks.
---
Zdenek Kotala wrote:
> Peter Eisentraut wrote:
> >
> > The way I see it, combining a feature change with a code refactoring and
> > random white space changes is a pretty optimal way to get you
Patch applied. Thanks.
---
Pavel Stehule wrote:
> Hello,
>
> I send two small patches. First does conversion from perl to postgresql
> array in OUT parameters. Second patch allow hash form output from procedures
> with
This is an updated version of the PL instrumentation plugin patch that I submitted on July-28. The new version re-implements the plugin loader code to use "rendezvous variables" as suggested by Tom Lane (thanks Tom, very elegant design).
I have not implemented any support for unloading share
I don't see any documentation, so I assume you want me to add something
to README.pgstattuple.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
an
Hi all,
Here is a patch to add pgstatindex functions to the pgstattuple module,
which can work with 8.1.4. Please review and try it. Thanks.
Satoshi Nagayasu wrote:
> Bruce,
>
> I'll fix it in this week. Please wait a few days.
> Thanks.
>
> Bruce Momjian wrote:
>> nagayasu-san,
>>
>> This loo
On Thu, 2006-08-10 at 08:57 -0400, Tom Lane wrote:
> Anyway, after further thought I've concluded that we really should
> supply something that returns the Insert pointer, as this would be
> useful for debugging and system-monitoring purposes. It's clear however
> that we also need something that
12 matches
Mail list logo
