On Tue, Feb 28, 2017 at 9:41 AM, Adrian Klaver
wrote:
> On 02/27/2017 11:14 PM, Sasa Vilic wrote:
> ...
>
> "My problem is that sometimes WAL uploaded from master and from slave are
> not 100% identical. In most cases they are but occasionally they are not. I
> have written small script that en
On Sun, Feb 23, 2014 at 10:07 PM, Tom Lane wrote:
> Jon Nelson writes:
>> On Sun, Feb 23, 2014 at 9:49 PM, Tom Lane wrote:
>>> If memory serves, the inode should get removed during the next checkpoint.
>
>> I was moments away from commenting to say that I had traced
On Sun, Feb 23, 2014 at 9:49 PM, Tom Lane wrote:
> Jeff Janes writes:
>> On Sunday, February 23, 2014, Scott Marlowe wrote:
>>> I'm guessing that this is so that it can be rolled back. Unlink is
>>> likely issued at commit;
>
>> I would hope that ftruncate is issued at commit as well. That does
When dropping lots of tables, I noticed postgresql taking longer than
I would have expected.
strace seems to report that the largest contributor is the ftruncate
and not the unlink. I'm curious what the logic is behind using
ftruncate before unlink.
I'm using an ext4 filesystem.
--
Jon
--
Se
On Wed, Apr 4, 2012 at 12:51 PM, Thomas Kellerer wrote:
> Jon Nelson wrote on 04.04.2012 19:47:
>
>>> What about a set-returning function that builds the query dynamically and
>>> wrapping that into a view?
>>>
>>> That way the view would ne
On Wed, Apr 4, 2012 at 11:22 AM, Thomas Kellerer wrote:
> Jon Nelson wrote on 04.04.2012 15:50:
>
>> I need to have something table-like from the client's perspective for
>> a bunch of reasons.
>> For now, assume that I want to keep using the view and that I
On Wed, Apr 4, 2012 at 10:43 AM, Tom Lane wrote:
> Jon Nelson writes:
>> On Wed, Apr 4, 2012 at 9:01 AM, Tom Lane wrote:
>>> Why aren't you using a standard partitioned table, cf
>>> http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html
>
>> Be
On Wed, Apr 4, 2012 at 9:01 AM, Tom Lane wrote:
>
> Why aren't you using a standard partitioned table, cf
> http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html
Because I'm adding "scalar" (constant-value) columns to the view like this:
SELECT * from tableA, DATE 'date string here' as
On Tue, Apr 3, 2012 at 8:58 PM, Scott Marlowe wrote:
> On Tue, Apr 3, 2012 at 7:21 PM, Jon Nelson wrote:
>> On Tue, Apr 3, 2012 at 2:45 PM, Thomas Kellerer wrote:
>>> Jon Nelson wrote on 03.04.2012 20:41:
>>>
>>>> Close, but not quite. It's not rot
On Tue, Apr 3, 2012 at 2:45 PM, Thomas Kellerer wrote:
> Jon Nelson wrote on 03.04.2012 20:41:
>
>> Close, but not quite. It's not rotation but every N minutes a
>> newly-built table appears. I'd like that table to appear as part of
>> the view as soon as p
On Tue, Apr 3, 2012 at 1:36 PM, Merlin Moncure wrote:
> On Tue, Apr 3, 2012 at 12:30 PM, Jon Nelson wrote:
>> On Tue, Apr 3, 2012 at 12:16 PM, Merlin Moncure wrote:
>>> On Tue, Apr 3, 2012 at 12:01 PM, Jon Nelson
>>> wrote:
>>>> I have a situation that I
On Tue, Apr 3, 2012 at 12:16 PM, Merlin Moncure wrote:
> On Tue, Apr 3, 2012 at 12:01 PM, Jon Nelson wrote:
>> I have a situation that I'd like some help resolving.
>> Using PostgreSQL 8.4. on Linux, I have three things
>> coming together that cause me pain. I have
I have a situation that I'd like some help resolving.
Using PostgreSQL 8.4. on Linux, I have three things
coming together that cause me pain. I have a VIEW used by a bunch of
queries. Usually, these queries are fairly short (subsecond) but
sometimes they can be very long (days). I also update this
On Sat, Mar 3, 2012 at 8:23 PM, David Boreham wrote:
> On 3/3/2012 7:05 PM, Tom Lane wrote:
>>
>>
>> [ raised eyebrow... ] As the person responsible for the packaging
>> you're dissing, I'd be interested to know exactly why you feel that
>> the Red Hat/CentOS PG packages "can never be trusted".
On Sun, Jan 8, 2012 at 7:13 PM, 邓尧 wrote:
> I have enabled the autocommit feature of psycopg2, and removed all the
> transactions in source code, also changed the sql statement to the
> following:
>
> insert into ACCOUNT(HOME)
> select "v1" as HOME
> where not exists (select 1 from ACCOUNT
On Thu, Sep 29, 2011 at 10:51 AM, David North wrote:
> I'll also apply GZip to keep the amount of data in any given bytea/lob as
> small as possible.
Aren't bytea fields compressed by postgresql anyway (when EXTENDED or
MAIN is used) (by default).
http://www.postgresql.org/docs/8.4/static/stora
On Thu, Sep 29, 2011 at 7:30 AM, Alban Hertroys wrote:
> On 29 September 2011 13:12, Radosław Smogura wrote:
>>> sending ~1GB bytea values is borderline crazy, and is completely crazy
>>> if you are not absolutely sure the transmission is not 100% binary. I
>>> don't know if the JDBC sends/recei
On Tue, Sep 20, 2011 at 2:09 PM, Josh Kupershmidt wrote:
> On Tue, Sep 20, 2011 at 1:26 PM, Jon Nelson wrote:
>> I have a table with a fair bit of TOAST data in it.
>> I noticed that \d+ does /not/ include that information (but
>> pg_total_relation_size does).
>
>
I have a table with a fair bit of TOAST data in it.
I noticed that \d+ does /not/ include that information (but
pg_total_relation_size does).
Is that intentional? It seems a bit misleading, insofar as "\d+" feels
like it is meant to be a rough indication of the table size, but if
90% of the data is
On Mon, Mar 21, 2011 at 7:16 PM, John R Pierce wrote:
> On 03/21/11 5:04 PM, Tomas Vondra wrote:
>>
>> So just put there a tripod, a reasonable HD cam for $300 and you'll get
>> a decent video of the session.
>>
>
> you definitely want a sound patch from a lapel mic or the room PA, and not
> be us
I am working with a system which periodically has to perform this operation:
update all of the rows in table A which match rows in table B, using a
subset of the columns for comparison (and one of the columns in tableA
is NULL).
This is what I've tried:
update tableA
SET column1 = some_value
FRO
On Mon, Feb 14, 2011 at 11:57 AM, David Johnston wrote:
> You cannot ALWAYS do an indexed scan - sometimes the only option for the
> parser is to do a sequential scan (thus you can say "avoid unless you have
> to" but you can never truly disable sequential scanning).
>
Does this suggest that the
On Fri, Feb 4, 2011 at 1:18 PM, Tom Lane wrote:
> Jon Nelson writes:
>> I thought 'character varying' (aka varchar) sans length was an alias
>> for text. Is it not?
>
> It has the same behavior, but it is a distinct type, so dummy coercions
> are needed.
Are
Let's say I have a database with two tables, a and b.
Each has one column. 'a' has a column 't' of type text. 'b' has a
column 'v' of type 'varchar' (no length specified).
If I join the two tables, I see in the plan something that looks like this:
Merge Cond: (a.t = (b.v)::text)
I thought 'char
On Fri, Dec 31, 2010 at 1:13 PM, bricklen wrote:
> On Wed, Dec 29, 2010 at 1:53 PM, bricklen wrote:
>> On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane wrote:
>>>
>>> The difference in ctid, and the values of xmin and relfrozenxid,
>>> seems to confirm my suspicion that this wasn't just random cosmic
On Wed, Dec 8, 2010 at 7:15 AM, Andre Lopes wrote:
> Hi,
>
> I need to obtain the maximum value of a date, but that comparison will be
> made between 3 tables... I will explain better with a query...
>
> [code]
> select
> a.last_refresh_date as d1, ae.last_refresh_date as d2, ha.last_refresh_date
On Tue, Dec 7, 2010 at 9:17 AM, Steve Clark wrote:
> Hello All,
>
> I am working with a postgresql database that has two columns.
> One for an ip address and another for the netmask. Both of these
> columns are char varying(30). I would like to convert to just
> one column as inet. Any one know a
On Fri, Nov 19, 2010 at 1:09 PM, Tom Lane wrote:
> Jon Nelson writes:
>> On Fri, Nov 19, 2010 at 12:14 PM, Tom Lane wrote:
>>> Hard to comment about this with such an incomplete view of the situation
>>> --- in particular, data types would be a critical factor, and
On Fri, Nov 19, 2010 at 12:14 PM, Tom Lane wrote:
> Jon Nelson writes:
>> What influences the calculation of the 'width' value in query plans?
>
> It's generally the sum of the estimated column widths for all the
> columns needed at that particular level of th
What influences the calculation of the 'width' value in query plans?
Specifically, I have two queries which both query the same set of
tables via either UNION or UNION ALL based on the presence (or
absence) of an aggregate function.
Like this:
SELECT a, b FROM foo_1 WHERE a = 'bar'
UNION
SELECT a
30 matches
Mail list logo
