Sent from my iPad
On 08-Sep-2013, at 4:27, Tomas Vondra wrote:
> On 5.9.2013 09:36, Atri Sharma wrote:
>> On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera
>> wrote:
>>> Satoshi Nagayasu wrote:
>>>
But, for now, I think we should have a real index for the
statistics data because we
Sent from my iPad
On 08-Sep-2013, at 4:27, Tomas Vondra wrote:
> On 5.9.2013 09:36, Atri Sharma wrote:
>> On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera
>> wrote:
>>> Satoshi Nagayasu wrote:
>>>
But, for now, I think we should have a real index for the
statistics data because we
On 5.9.2013 07:29, Alvaro Herrera wrote:
> Satoshi Nagayasu wrote:
>
>> But, for now, I think we should have a real index for the
>> statistics data because we already have several index storages, and
>> it will allow us to minimize read/write operations.
>>
>> BTW, what kind of index would be p
On 5.9.2013 09:36, Atri Sharma wrote:
> On Thu, Sep 5, 2013 at 10:59 AM, Alvaro Herrera
> wrote:
>> Satoshi Nagayasu wrote:
>>
>>> But, for now, I think we should have a real index for the
>>> statistics data because we already have several index storages,
>>> and it will allow us to minimize
> Should these patches be applied?
I have a copy of the program and was going to take care of this.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2013-09-07 12:50:59 -0400, Bruce Momjian wrote:
> That seems very complicated. I think it would be enough to record the
> current xid at the time of the vacuum, and when testing for later
> vacuums, if that saved xid is earlier than the RecentGlobalXmin, and
> there have been no inserts/up
2013/9/7 Gilles Darold
> Le 07/09/2013 10:02, Pavel Stehule a écrit :
> > Hello
> >
> > * patch is cleanly patchable and compilation is without warnings
> > * all regression tests passed
> > * no impact on dump, performance or any current features
> > * no comments to programming style
> > * we w
On Sat, Sep 07, 2013 at 05:21:31PM +0200, Kohei KaiGai wrote:
> 2013/9/7 David Fetter :
> > The broad outlines look great.
> >
> > Do we have any way, at least conceptually, to consider the graph
> > of the cluster with edges weighted by network bandwidth and
> > latency?
> >
> As postgres_fdw is n
On Mon, Jul 15, 2013 at 06:19:27PM -0400, Alvaro Herrera wrote:
> Robert Haas escribió:
> > On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
> > wrote:
> > > Xi Wang escribió:
> > >> Intel's icc and PathScale's pathcc compilers optimize away several
> > >> overflow checks, since they consider signe
On Thu, Jan 31, 2013 at 03:49:36PM -0500, Peter Eisentraut wrote:
> On 1/9/13 8:56 PM, Tom Lane wrote:
> > However, it seems to me that this behavior is actually wrong for our
> > purposes, as it represents a too-literal reading of the spec. The SQL
> > standard has no concept of privileges on sch
On Sat, Sep 7, 2013 at 07:34:49AM +0200, Andres Freund wrote:
> > The idea of using RecentGlobalXmin to see how much _work_ has happened
> > since the last vacuum is interesting, but it doesn't handle read-only
> > transactions; I am not sure how they can be tracked. You make a good
> > point th
On Sat, Sep 7, 2013 at 10:59:08AM -0400, Bruce Momjian wrote:
> My original problem report was November, 2012:
>
> http://www.postgresql.org/message-id/50b3d11f.20...@2ndquadrant.com
>
> and my patch to fix this was July 4. Tom gave me a code snipped to test
> PL/pgSQL's handling of recor
Le 07/09/2013 10:02, Pavel Stehule a écrit :
> Hello
>
> * patch is cleanly patchable and compilation is without warnings
> * all regression tests passed
> * no impact on dump, performance or any current features
> * no comments to programming style
> * we would this feature - it is consistent with
2013/9/7 David Fetter :
> On Sat, Sep 07, 2013 at 02:49:54PM +0200, Kohei KaiGai wrote:
>> 2013/9/7 Kohei KaiGai :
>> > 2013/9/7 Tom Lane :
>> >> Robert Haas writes:
>> >>> I find this a somewhat depressing response. Didn't we discuss this
>> >>> exact design at the developer meeting in Ottawa?
On Sat, Sep 7, 2013 at 07:42:55AM +0200, Andres Freund wrote:
> On 2013-09-06 23:07:04 -0400, Bruce Momjian wrote:
> > On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> > > >> Another poss
On Sat, Sep 07, 2013 at 02:49:54PM +0200, Kohei KaiGai wrote:
> 2013/9/7 Kohei KaiGai :
> > 2013/9/7 Tom Lane :
> >> Robert Haas writes:
> >>> I find this a somewhat depressing response. Didn't we discuss this
> >>> exact design at the developer meeting in Ottawa? I thought it sounded
> >>> reas
> 2) there is only one open question
> http://www.postgresql.org/message-id/b6f6fd62f2624c4c9916ac0175d56d880ce00...@jenmbs01.ad.intershop.net
> -
> there is no clean relation between output and some pset option.
> I don't think so Marc' proposal is ideal (these values are not a variables) -
>
2013/9/7 Kohei KaiGai :
> 2013/9/7 Tom Lane :
>> Robert Haas writes:
>>> I find this a somewhat depressing response. Didn't we discuss this
>>> exact design at the developer meeting in Ottawa? I thought it sounded
>>> reasonable to you then, or at least I don't remember you panning it.
>>
>> Wha
On Thu, Sep 5, 2013 at 12:27 PM, wrote:
> I had committed the patch to the Server Features
> (https://commitfest.postgresql.org/action/commitfest_view/open).
> Is this right ? If not, please give me more advice,thanks !
Yes this category is fine don't worry.
--
Michael
--
Sent via pgsql-hacke
Thank you for your opinions and ideas.
From: "Tom Lane"
Greg Stark writes:
What would be nicer would be to display the C define, EINVAL, EPERM, etc.
Afaik there's no portable way to do that though. I suppose we could just
have a small array or hash table of all the errors we know about and lo
Hello
* patch is cleanly patchable and compilation is without warnings
* all regression tests passed
* no impact on dump, performance or any current features
* no comments to programming style
* we would this feature - it is consistent with \set and it gives a fast
resume about psql printer settin
Hello
when I checked "psql and pset without any arguments" patch, I found so only
popt->topt.line_style is initialized to NULL as default. All other popt
variables are not null.
Can we fixed?
Regards
Pavel
22 matches
Mail list logo
