Hi
2016-10-08 23:46 GMT+02:00 Jim Nasby :
> On 10/3/16 3:18 PM, Pavel Stehule wrote:
>
>> I am feeling consensus on removing source of PL from \dt+. There is
>> partial consensus on saving this field (renamed) for C and internal
>> language. I am not sure about consensus about \sf enhancing.
>>
>
2016-10-09 7:54 GMT+02:00 Amit Kapila :
> On Sat, Oct 8, 2016 at 5:52 PM, Michael Paquier
> wrote:
> > On Sat, Oct 8, 2016 at 9:12 PM, Amit Kapila
> wrote:
> >> On Fri, Oct 7, 2016 at 10:16 PM, Alvaro Herrera
> >> wrote:
> >>> Robert Haas wrote:
> On Wed, Oct 5, 2016 at 10:58 AM, Francisco
On Sat, Oct 8, 2016 at 5:52 PM, Michael Paquier
wrote:
> On Sat, Oct 8, 2016 at 9:12 PM, Amit Kapila wrote:
>> On Fri, Oct 7, 2016 at 10:16 PM, Alvaro Herrera
>> wrote:
>>> Robert Haas wrote:
On Wed, Oct 5, 2016 at 10:58 AM, Francisco Olarte
I don't know, but it seems like the document
Apologies for the delayed response to this.
On Tue, Oct 4, 2016 at 3:47 AM, Heikki Linnakangas wrote:
> One of the patches in Peter Geoghegan's Parallel tuplesort patch set [1] is
> to put a cap on the number of tapes to use for the sort.
> That amounts to about 8% of the available memory. That'
On 10/3/16 3:18 PM, Pavel Stehule wrote:
I am feeling consensus on removing source of PL from \dt+. There is
partial consensus on saving this field (renamed) for C and internal
language. I am not sure about consensus about \sf enhancing.
FWIW, I'm completely in favor of ditching PL source code.
Robert Haas writes:
> On Thu, Oct 6, 2016 at 9:46 AM, Tom Lane wrote:
>> Can anyone think of a test case that would stress semaphore operations
>> more heavily, without being unrealistic?
> I think it's going to be pretty hard to come up with a non-artificial
> test case that has exhibits meanin
On Fri, Oct 7, 2016 at 8:51 AM, Jeff Janes wrote:
>
> I think we need to come up with some benchmarking queries which get more
> work done per round-trip to the database. And build them into the binary,
> because otherwise people won't use them as much as they should if they have
> to pass "-f" f
On Fri, Oct 7, 2016 at 11:14 PM, Amit Kapila
wrote:
>
> > Another strategy that may work is actually intentionally
> waiting/buffering
> > some few ms between flushes/fsync,
>
> We do that before attempting to write if user has set "commit_delay"
> and "commit_siblings" guc parameters.
>
If you
On Fri, Oct 7, 2016 at 1:28 PM, Robert Haas wrote:
> On Fri, Oct 7, 2016 at 11:51 AM, Jeff Janes wrote:
> > What happens if you turn fsync off? Once a xlog file is fully written,
> it
> > is immediately fsynced, even if the backend is holding WALWriteLock or
> > wal_insert (or both) at the time
Hello,
Would it be possible to regularly build and provide a .pdf of the
development version?
Ideally, it would show up on
https://www.postgresql.org/docs/manuals/
(I know there is already a html devel version available.)
thanks,
Erik Rijkers
--
Sent via pgsql-hackers mailing li
Hi.
(if this is not the right forum, please point me to it)
I have an issue with pg_upgrade upgrading 9.5 to 9.6. (my system is
Ubuntu-16.04 and packages from http://apt.postgresql.org/)
In short pg_upgrade fails with:
Linking user relation files
No match found in new cluster for old rela
Hello Amit.
Also, given the heavy UPDATE nature of the pgbench test, a non 100% default
fill factor on some tables would make sense.
FWIW, sometime back I have seen that with fill factor 80, at somewhat
moderate client counts (32) on 192 - Hyper Threaded m/c, the
performance is 20~30% better,
On Sat, Oct 8, 2016 at 9:12 PM, Amit Kapila wrote:
> On Fri, Oct 7, 2016 at 10:16 PM, Alvaro Herrera
> wrote:
>> Robert Haas wrote:
>>> On Wed, Oct 5, 2016 at 10:58 AM, Francisco Olarte
>>> I don't know, but it seems like the documentation for vacuumdb
>>> currently says, more or less, "Hey, if y
On Fri, Oct 7, 2016 at 10:16 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Wed, Oct 5, 2016 at 10:58 AM, Francisco Olarte
>> I don't know, but it seems like the documentation for vacuumdb
>> currently says, more or less, "Hey, if you use -j with -f, it may not
>> work!", which seems unaccep
On Sat, Oct 8, 2016 at 2:59 AM, Stephen Frost wrote:
> Another approach to this would be to figure out a way for the newer
> testing framework in HEAD to be run against older versions, though we'd
> need to have a field which indicates which version of PG a given test
> should be run against as th
On Sat, Oct 8, 2016 at 12:58 PM, Fabien COELHO wrote:
>
> Hello Tom,
>
> I comment here on the first part of your remarks. I've answered the second
> part in another mail.
>
>>> (1) The required schema is slightly different : currently the type used
>>> for holding balances is not wide enough per
Hello Tom,
I comment here on the first part of your remarks. I've answered the second
part in another mail.
(1) The required schema is slightly different : currently the type used
for holding balances is not wide enough per the TCP-B standard, this mean
maybe having an option to do "pgbench
17 matches
Mail list logo