Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGQnG-0002UP-To for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 16:18:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hGQnF-0004z1-Qp for pgsql-hackers@arkaria.postgresql.org; Tue, 16 Apr 2019 16:18:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGQkG-0004Ew-IE for pgsql-hackers@lists.postgresql.org; Tue, 16 Apr 2019 16:15:40 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGQkD-0002Gb-I0 for pgsql-hackers@postgresql.org; Tue, 16 Apr 2019 16:15:40 +0000 Received: by mail-wr1-x444.google.com with SMTP id w1so27916550wrp.2 for ; Tue, 16 Apr 2019 09:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/Tl453vjgXDSumr7vOg6Tlv90eDtJaK3l/otuVuk4oY=; b=SamS9+vtJAP9NAYlnGNO1J+9nUh0AXrvhragaiq2f51+im2cwsxtWGm0LTC0Fz0qyJ fNO5PqyiOKMPwYZAQZErpVNTMefoV8/JxTKO0PUL18pnnb23WifM0ZL3SiYQu3BiMdpl BiAh4b6Lk0V8i4FlLPr/w7+wJtKJdw9RI1w7Q3cjBi83Iod81DWk8lwMMTBYY24LSp1S BLZ/BZEeyCkp0LCWosl5Ru54I7bNEnjZyJrVVdcd5qok/7n02JaODniYlJ4CxBmMMTNE VuxHC+yhV5l6NU3gorMYhVKnsxMk27dvk6MxOZZy/J56HWRvt+bVTdX2SD8IqRpTnd32 xwjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/Tl453vjgXDSumr7vOg6Tlv90eDtJaK3l/otuVuk4oY=; b=NJDg6watYUntHnv/zygvH5yAg3BYM8U2aUAM4TZJle7woltXF2+Y86XqNtuSjNLlDE iTxjvUiI8jTvm35C0+MbVhchAN0DSQD7IdNINbJX31sSpPboas1ms2u6ZBWxM7r5ZyXo BmX6bvHBX/0NA2qeSTGrOxC/0J4g2w+TCY1QUJi6eqqx7talaQ7pFSvnNoWWXvjbrJS/ AYRATftKs13YnxHCtLDw4EOI2NkbcszdL/YZcOQ6AyEOxRrmARpUC+veNg3OD8+VcOpP etN9N/w10LtGUXIjYo1wiUb2/FS5pykJZcv7Kqpmw6tZh8xvRJcZ+LVG55Kkm1lyoy0Z 95/Q== X-Gm-Message-State: APjAAAWTgHNKhcVP36x/O+stRngPMD19rt+8JxGWZ7G7//6+5qU9e9xH yWkSzrEfodwl9TWXs/ReWGkZOA== X-Google-Smtp-Source: APXvYqzbaGKtux44GvBvKTBcqppT32ubMxbDBYZ04pPscxCHjzT4cnCPc946QS2OS4YHAbdg1wTBJw== X-Received: by 2002:a5d:6406:: with SMTP id z6mr30983533wru.266.1555431336134; Tue, 16 Apr 2019 09:15:36 -0700 (PDT) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id h10sm94657175wrs.27.2019.04.16.09.15.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 09:15:25 -0700 (PDT) Date: Tue, 16 Apr 2019 18:15:24 +0200 From: Tomas Vondra To: Ashwin Agrawal Cc: Peter Geoghegan , Rafia Sabih , PostgreSQL mailing lists Subject: Re: Zedstore - compressed in-core columnar storage Message-ID: <20190416161524.bxqdduppb55yasbg@development> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-1444-295967-dirty List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Apr 15, 2019 at 10:45:51PM -0700, Ashwin Agrawal wrote: >On Mon, Apr 15, 2019 at 12:50 PM Peter Geoghegan wrote: > >> On Mon, Apr 15, 2019 at 9:16 AM Ashwin Agrawal >> wrote: >> > Would like to know more specifics on this Peter. We may be having >> different context on hybrid row/column design. >> >> I'm confused about how close your idea of a TID is to the traditional >> definition from heapam (and even zheap). If it's a purely logical >> identifier, then why would it have two components like a TID? Is that >> just a short-term convenience or something? >> > >TID is purely logical identifier. Hence, stated in initial email that for >Zedstore TID, block number and offset split carries no meaning at all. It's >purely 48 bit integer entity assigned to datum of first column during >insertion, based on where in BTree it gets inserted. Rest of the column >datums are inserted using this assigned TID value. Just due to rest to >system restrictions discussed by Heikki and Andres on table am thread poses >limitations of value it can carry currently otherwise from zedstore design >perspective it just integer number. > I'm not sure it's that clear cut, actually. Sure, it's not the usual (block,item) pair so it's not possible to jump to the exact location, so it's not the raw physical identifier as regular TID. But the data are organized in a btree, with the TID as a key, so it does actually provide some information about the location. I've asked about BRIN indexes elsewhere in this thread, which I think is related to this question, because that index type relies on TID providing sufficient information about location. And I think BRIN indexes are going to be rather important for colstores (and formats like ORC have something very similar built-in). But maybe all we'll have to do is define the ranges differently - instead of "number of pages" we may define them as "number of rows" and it might be working. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services