On 2018-02-28 13:15:45 +1300, David Rowley wrote:
> On 28 February 2018 at 11:11, Andres Freund wrote:
> > I'm fairly certain that only vacuum and table rewrites like cluster sets
> > all-visible,
>
> I don't think the pages are set all visible again after a rewrite.
You're right. We freeze the
Hi. Thanks so much for your assistance. This is definitely getting the
results I was looking for. It is still syntacticallly more cumbersome than
I might have hoped, but I can work with it. So I've got two follow
questions/issues:
1) I can see there are many, more complex, options for aggrega
On 28 February 2018 at 11:11, Andres Freund wrote:
> I'm fairly certain that only vacuum and table rewrites like cluster sets
> all-visible,
I don't think the pages are set all visible again after a rewrite.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development,
You can access code with
git clone ssh://@git.code.sf.net/p/pg-scd/code
pg-scd-code
and browse it at
https://sourceforge.net/p/pg-scd/code/
On 02/27/18 08:43, Thiemo Kellner wrote:
I attached what I have got so far. I will setup a shared repository
these days.
Zitat von Thiemo Kellner :
Hi
On Wed, Feb 28, 2018 at 10:27:23AM +1300, Thomas Munro wrote:
Tom K, if you need a workaround before 10.4 comes out in May[1], you
could try selecting the whole transition table into a CTE up front.
Something like WITH my_copy AS (SELECT * FROM new_table) SELECT * FROM
my_copy UNION ALL SELECT *
On 2018-02-27 16:58:11 -0500, Tom Lane wrote:
> > Also, I recall discussion that select statements will touch the visibility
> > map (hence causing write I/O even in a read-only query) but [1] indicates
> > that only vacuum will set them ddl will clear them.
>
> Hm, I don't recall that, but I've n
On Tue, Feb 27, 2018 at 2:58 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>
> > Also, I recall discussion that select statements will touch the
> visibility
> > map (hence causing write I/O even in a read-only query) but [1] indicates
> > that only vacuum will set them ddl will clear them
"David G. Johnston" writes:
> If one runs vacuum on a table (small or otherwise) that is currently
> choosing an index scan as its best plan how likely is it that post-vacuum
> an index-only plan would be chosen if the index type and column presence
> conditions are met?
Offhand I think it would
On Tue, Feb 27, 2018 at 03:58:14PM -0500, Tom Lane wrote:
Thomas Munro writes:
Here's a new version with tuplestore_select_read_pointer() added in
another place where it was lacking, and commit message. Moving to
-hackers, where patches go.
Pushed, along with a regression test based on your
On Wed, Feb 28, 2018 at 9:58 AM, Tom Lane wrote:
> Thomas Munro writes:
>> Here's a new version with tuplestore_select_read_pointer() added in
>> another place where it was lacking, and commit message. Moving to
>> -hackers, where patches go.
>
> Pushed, along with a regression test based on you
On Tue, Feb 27, 2018 at 2:08 PM, Tom Lane wrote:
> Hadi Moshayedi writes:
> > I am wondering why is it not using index-only-scan (which would use the
> > cache better) and instead it does a bitmap scan?
>
> Never experiment on an empty table and assume that the resulting plan
> is the same as yo
Hadi Moshayedi writes:
> I am wondering why is it not using index-only-scan (which would use the
> cache better) and instead it does a bitmap scan?
Never experiment on an empty table and assume that the resulting plan
is the same as you'd get on a large table.
In this case, not only don't you ha
Thomas Munro writes:
> Here's a new version with tuplestore_select_read_pointer() added in
> another place where it was lacking, and commit message. Moving to
> -hackers, where patches go.
Pushed, along with a regression test based on your example.
Unfortunately, this came in a bit too late for
With the following definition:
create table t1 (a int, b int, c int);
create index on t1 (a,b,c);
I get the following plan for the following query:
postgres=# explain select sum(c) from t1 where a > 0;
QUERY PLAN
--
With the following definition:
create table t1 (a int, b int, c int);
create index on t1 (a,b,c);
I get the following plan for the following query:
postgres=# explain select sum(c) from t1 where a > 0;
QUERY
PLAN
---
On 02/27/2018 12:16 PM, chris wrote:
>
> What is the best way of selecting current timestamp in UTC?
>
> SELECT
> CURRENT_TIMESTAMP as ct1
> ,timezone('UTC',CURRENT_TIMESTAMP) as ct2
> ,timezone('utc',now()) as ct3
> ,CURRENT_TIMESTAMP at time zone 'UTC' as ct4
> ,NOW() at time zone 'utc' as c
On Tue, Feb 27, 2018 at 1:16 PM, chris wrote:
>
> What is the best way of selecting current timestamp in UTC?
>
You
haven't
define
d
criteria upon which to judge - and the list below is not exhaustive
(but sufficiently so)
>
> SELECT
> CURRENT_TIMESTAMP as ct1
>
standard conformi
On 02/27/2018 12:16 PM, chris wrote:
What is the best way of selecting current timestamp in UTC?
SELECT
CURRENT_TIMESTAMP as ct1
Well the above would depend on your database having its time zone
set to UTC.
,timezone('UTC',CURRENT_TIMESTAMP) as ct2
,timezone('utc',now()) as ct3
,CURRENT_T
What is the best way of selecting current timestamp in UTC?
SELECT
CURRENT_TIMESTAMP as ct1
,timezone('UTC',CURRENT_TIMESTAMP) as ct2
,timezone('utc',now()) as ct3
,CURRENT_TIMESTAMP at time zone 'UTC' as ct4
,NOW() at time zone 'utc' as ct5
On 18 November 2016 at 13:00, otheus uibk wrote:
> What I do today is to configure postgresql to write csvlogs. Stdout/stderr
> are captured by journald. A custom perl script with the Text::CSV module and
> tail -F semantics continuously processes the csvlog file, ignores query,
> dml, and detail
hello,
one more fix, to not let someone get incorrect/incomplete ideas, see
below
On Tue, 2018-02-27 at 10:03 +0100, mariusz wrote:
> On Fri, 2018-02-23 at 18:11 -0800, Ken Tanzer wrote:
> > On Fri, Feb 23, 2018 at 6:10 AM,
> > mariusz wrote:
> >
> >
> >
Hi Jacek,
On Mon, 26 Feb 2018 11:44:13 +0100
Łukasz Jarych wrote:
> Hi Guys,
>
> i would like to ask you for help with track changes to my database.
> I am new to PosgtreeSQL but i have to learn it quickly because of my boss.
>
> I have to:
>
> 1. Keep all changes within table including:
> -a
On 27 February 2018 at 18:03, Sam Saffron wrote:
> 1. Where is all my missing space, is this in page alignment stuff and
> per-page overhead?
Yes, tuples are MAXALIGNed when copied onto the page. That appears to
be 8 bytes on your system. You're just 2 bytes over the 8-byte
boundary. You'll notic
On Tue, 2018-02-27 at 10:03 +0100, mariusz wrote:
> On Fri, 2018-02-23 at 18:11 -0800, Ken Tanzer wrote:
> > On Fri, Feb 23, 2018 at 6:10 AM,
> > mariusz wrote:
> >
> >
> > i guess, you can easily get max continuous range for each row
> > with
>
On Fri, 2018-02-23 at 18:11 -0800, Ken Tanzer wrote:
> On Fri, Feb 23, 2018 at 6:10 AM,
> mariusz wrote:
>
>
> i guess, you can easily get max continuous range for each row
> with
> something like this:
>
> CREATE OR REPLA
25 matches
Mail list logo
